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PREFACE 


This  report  summarizes  the  work  completed  during  the  second  year  of  a  project  focused  on 
studies  of  the  effects  of  the  earth’s  ionosphere  on  transionospheric  radiowave  propagation. 

We  express  our  appreciation  to  SSgt.  Carlton  Curtis  of  Phillips  Laboratory  at  Hanscom  for  his 
collaboration  in  many  of  the  investigations  and  support  efforts  for  the  Ionospheric  Measuring 
System  and  other  TEC  and  scintillation  measurement  projects.  We  also  express  our  appreciation 
to  Peter  Ning  of  KEO  Consultants  for  his  guidance  and  assistance  in  analyzing  the  visual  all-sky 
images  from  the  1994  Chile  campaign. 
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1.  Introduction 

The  overall  objective  of  the  various  tasks  that  make  up  this  project  is  to  improve  our 
understanding  of  ionospheric  effects  on  transionospheric  radiowave  propagation.  The 
phenomena  to  be  studied  cover  the  full  range  of  scale  sizes  from  tens  of  meters  (scintillation 
effects)  to  thousands  of  kilometers  (large-scale  TEC  effects).  The  twelve  tasks  outlined  in  the 
proposal  for  this  work  [Fremouw  et  al,  1994]  can  be  grouped  into  the  following  six  study  areas. 
(The  tasks  in  the  proposal  corresponding  to  these  study  areas  are  indicated  in  parentheses.) 

1.  Investigate  the  logarithmic  slope  of  the  phase-scintillation  power-density  spectrum  (PDS)  at 
large  scales  in  the  equatorial  region.  Develop  a  model  for  a  two-regime  power-law  PDS 
based  on  the  results  of  the  investigation  and  implement  it  in  WBMOD.  (Tasks  1  and  2) 

2.  Investigate  the  magnitude  and  behavior  of  small-scale  phase  gradients  using  the  equatorial 
scintillation  data  sets  built  in  the  first  study.  Develop  algorithms  for  including  the  effects  of 
small-scale  phase  gradients  on  transionospheric  propagation  based  on  the  results  of  the 
investigation  and  implement  them  in  the  WBMOD  ionospheric  scintillation  model.  (Tasks  3 
and  4) 

3.  Develop  models  consistent  with  the  current  propagation  algorithm  in  WBMOD  for 
individual  intermediate-scale  ionospheric  features  associated  with  enhanced  scintillation 
(equatorial  depletion  plumes,  polar  patches,  auroral  boundary  blobs).  Implement  these  in 
WBMOD.  (Tasks  5  and  6) 

4.  Develop  techniques  for  producing  short-term  forecasts  of  scintillation  effects  over  large 
spatial  areas,  implementing  and  demonstrating  these  techniques  in  computer  programs. 
(Task  7) 

5.  Deploy,  operate,  and  maintain  satellite  receiver  instmmentation  on  a  long-term  basis  at  local 
and  remote  sites  to  collect  databases  of  ionospheric  Total  Electron  Content  (TEC)  and 
scintillation  observations.  Use  these  data  to  (a)  analyze  performance  of  ionospheric 
monitors,  (b)  validate  models  of  ionospheric  behavior,  and  (c)  develop/formulate  algorithms 
to  improve  the  performance  of  both  ionospheric  monitors  and  models.  (Tasks  8  and  9) 

6.  Deploy,  operate,  and  maintain  satellite  receiver  instmmentation  on  a  short-term  basis  at  local 
and  remote  sites  where  unique  opportunities  exist  for  enhancement  of  test  data  sets, 
particularly  where  other  instmments  have  been  deployed  to  collect  other  ionospheric 
measurements.  Collect  these  data,  and  ancillary  data  from  other  instmmentation,  into 
documented  data  sets  that  can  be  used  as  outlined  in  the  previous  study  description.  (Tasks 
8, 9,  and  12) 

[Note;  Task  1 1  is  not  explicitly  included  in  the  above  listing  as  it  includes  support  to  all  of  the 
various  tasks  described  in  the  proposal.] 


1 


2.  Ionospheric  Total  Electron  Content  Studies 

Investigations  of  ionospheric  Total  Electron  Content  (TEC)  are  being  performed  based  on  current 
data  acquired  from  the  Air  Force  Ionospheric  Measuring  System  (IMS)  stations  being  deployed 
globally,  as  well  as  other  measurement  systems  deployed  on  a  temporary  or  permanent  basis. 
Previously  acquired  data  are  also  being  processed  and  analyzed  to  investigate  ionospheric 
conditions  at  alternative  times  and  locations.  All  of  these  systems  utilize  single-frequency  or 
dual-frequency  GPS  receivers. 

The  sources  of  ionospheric-measurement  data  utilized  during  this  period  of  study  encompass 
the  following: 

1.  IMS  stations  deployed  at  Otis  Air  National  Guard  Base,  Massachusetts;  Croughton  Royal 
Air  Force  Base,  England;  Thule  Air  Base,  Greenland; 

2.  An  IMS  operating  at  Phillips  Laboratory  at  Hanscom,  Massachusetts,  for  check-out, 
diagnostic,  and  developmental  efforts,  prior  to  its  shipment  to  Eareckson  Air  Force  Station, 
Shemya,  Alaska; 

3.  Data  sets  recorded  at  Shemya,  Alaska,  by  the  Real-Time  Monitor  developed  by  the 
University  of  Texas  Applied  Research  Laboratory,  in  support  of  the  site  survey  for 
installation  of  the  IMS  at  that  site; 

4.  A  portable  single-frequency  GPS  receiver  deployed  for  an  ionospheric  study  campaign  at 
Agua  Verde,  Chile,  in  September  and  October  of  1994; 

5.  Data  available  on  electronic  networks  from  GPS  maintenance  and  research  centers. 

2.1  General  Analysis.  Assistance  was  provided  to  personnel  of  Phillips  Laboratory  at  Hanscom 
(PLH)  in  installing  and  configuring  software  on  a  notebook  PC  to  allow  data  collection  and  near- 
real-time  display  of  scintillation  and  TEC,  as  reported  by  a  single-frequency  GPS  receiver.  This 
system  was  deployed  on  relatively  short  notice  for  a  special  campaign  in  Italy.  Further  GPS  data- 
processing  procedures  and  programs  were  installed  on  another  notebook  PC  for  use  with  data 
collected  by  a  stand-alone  Ashtech  receiver  and  antenna  system.  This  notebook  system  is  also 
being  deployed  for  field  work  on  an  interim  basis,  was  used  during  this  period  to  evaluate  data 
collected  for  comparison  to  the  IMS  operating  at  PLH,  Thule,  and  Otis,  and  was  deployed  for  use 
during  the  site  survey  at  Shemya. 

Ionospheric  measurements  were  acquired  from  the  National  Oceanic  and  Atmospheric 
Administration's  (NOAA)  Continuously  Operating  Reference  Station  (CORS)  network,  which  is 
managed  by  the  National  Geodetic  Survey  (NGS),  for  their  station  at  Portsmouth,  New 
Hampshire.  Although  the  initial  data-acquisition  processing  was  different  for  these  data  sets, 
many  of  the  processing  steps  were  common  with  prior  processing  for  data  in  RINEX  format,  and 
two  days  of  data  (95-169,  95-174)  were  evaluated  for  satellite  and  receiver  biases.  A  bias  shift  of 
about  9  TEC  units  is  evident  between  the  two  days,  which  is  compatible  with  the  reported  change 
in  receivers. 

Procedures  have  been  developed  to  utilize  the  standard  Windows-NT  FTP  utility  to  retrieve 
TEC  data  files  from  either  the  NOAA  CORS  network,  or  the  Jet  Propulsion  Laboratory  (JPL) 


distribution  center.  Additional  procedures  were  developed  to  convert  these  files  into  a  standard 
format  suitable  for  display  and  analysis. 

The  dialup  process  of  obtaining  GPS  almanac  files  from  Holloman  AFB,  New  Mexico,  was 
almost  totally  automated,  and  now  requires  only  a  simple  manual  initiation  to  update  the  existing 
archive  of  almanac  files.  Almanac  files  are  retrieved  as  needed  for  calibration  calculations  and 
other  GPS  ephemeris  studies. 

Two  programs  were  developed  to  address  data  anomalies  that  can  severely  affect  the  bias 
determinations  for  dual-frequency  GPS  systems,  reducing  the  need  for  manual  review  and  editing 
of  the  data  or  even  possible  elimination  of  some  data  segments.  The  first  program  was  developed 
to  address  the  problem  of  discontinuities  in  the  Differential  Carrier  Phase  (DCP)  during  a 
satellite  pass,  generally  caused  by  a  loss  of  lock  in  tracking  the  satellite.  The  amplitude  of  the 
phase  discontinuity  is  estimated  from  the  DCP  profile  on  either  side  of  the  discontinuity,  and  the 
subsequent  portion  of  the  DCP  profile  is  adjusted  by  this  amount  to  produce  a  more  smoothly 
varying  slant  TEC  profile.  This  editing  step  precedes  the  phase-averaging  process  used  to  align 
the  DCP  with  the  Differential  Group  Delay  (DGD),  and  enhances  that  process  by  allowing 
averaging  over  a  longer  time  interval.  The  second  program  was  developed  to  eliminate 
unreasonable  DGD  values,  which  generally  occur  when  a  satellite  is  first  acquired  for  tracking  or 
at  low  elevations.  This  step  also  enhances  the  phase-averaging  process,  because  extreme  DGD 
outliers  can  seriously  degrade  the  accuracy  for  phase-averaging.  Additional  enhancements  were 
incorporated  into  data-processing  programs  for  bias  calculations,  to  estimate  the  error  arising 
from  phase-averaging. 

An  investigation  was  conducted  into  the  effects  of  utilizing  an  elevation-dependent 
weighting  function  for  phase-averaging,  to  alleviate  the  influence  of  noise  in  the  DGD  signal  at 
low  elevations.  In  conjunction  with  this  study,  the  plotting  program  used  to  display  the 
differential  group  and  phase  data  was  extended  to  allow  these  quantities  to  be  overplotted  on  the 
same  frame.  Further  effort  is  required  to  pursue  this  investigation. 

The  bias-calculation  method  was  examined  for  effects  of  decimating  data,  to  evaluate  the 
computational  speed  advantages  against  the  potential  loss  of  accuracy.  A  significant 
computational  time  reduction  was  obtained  with  relatively  minor  bias  errors  (less  than  0.5  TEC 
units)  up  to  a  decimation  factor  of  40,  corresponding  to  one  data  sample  every  20  minutes.  The 
computational  time  required  at  this  level  of  decimation  was  less  than  one  minute,  on  a  90  MHz 
Pentium.  Results  of  this  investigation  are  displayed  in  Figure  1. 

The  sensitivity  of  the  bias-calculation  method  to  the  absence  of  one  or  more  satellites  from 
the  data-collection  set  was  also  investigated.  Using  bias  values  determined  from  a  full 
complement  of  25  GPS  satellites  as  a  reference,  comparative  bias  values  were  calculated  for  the 
successive  elimination  of  individual  satellites,  up  to  a  total  of  eight  satellites.  For  the  particular 
sequence  of  eliminations  used,  the  maximum  error  in  the  calculated  biases  was  only  one  TEC 
unit.  These  results  have  applicability  to  the  comparison  of  measurements  performed  at  different 
GPS  receiver  sites,  where  the  satellite  coverage  varies. 
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A 
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Figure  1.  A.  Processing  time  for  bias  calculations  with  varying  degrees  of  data  decimation.  B. 
Maximum  bias  error,  in  TEC  units,  for  bias  calculation  with  varying  degrees  of  data 
decimation. 

The  applicability  of  the  bias  determination  to  short  time  intervals  was  investigated  by 
performing  the  bias  calculations  for  six-hour  intervals  at  seven  overlapping  periods  within  a  day, 
for  each  of  six  days.  The  multipath  error  effect  for  phase-averaging  was  minimized  for  these 
tests  by  performing  phase-averaging  over  complete  passes,  but  significant  bias  errors  were  still 
observable  for  passes  that  were  only  marginally  included  in  the  six-hour  intervals.  Restricting 
the  calculation  to  passes  that  substantially  overlapped  the  interval  produced  improvement,  but 
still  generated  distinct  differences  in  the  vertical  TEC  profile  and  in  the  estimated  receiver  biases 
of  up  to  four  TEC  units. 
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The  detectability  of  errors  in  the  bias  determinations  was  investigated  by  introducing 
artificial  shifts  in  the  bias  values  and  examining  the  resulting  diurnal  vertical  TEC  profiles.  A 
marginal  decrease  in  the  self-consistency  of  the  diurnal  profile  is  evident  for  a  bias  shift  of  one 
TEC  unit,  and  a  generally  perceptible  decrease  in  the  self-consistency  of  the  diurnal  profile  is 
evident  for  a  bias  shift  of  three  TEC  units. 

The  standard  plotting  program  for  displaying  diurnal  vertical  TEC  profiles  was  enhanced  to 
allow  Universal  Time  (UT)  to  be  used  as  the  independent  variable,  instead  of  the  local  time  at  the 
Ionospheric  Penetration  Point  (BPP).  This  plotting  enhancement  allows  the  satellite  coverage  to 
be  displayed  in  terms  of  the  actual  data-acquisition  time. 

Previous  calibration  of  data  from  94-1 14  collected  by  PLH  on-site  at  Hanscom  AFB,  MA, 
and  by  the  Jet  Propulsion  Laboratory  at  Westford,  MA,  yielded  diurnal  TEC  variations  that 
diverged  over  the  latter  half  of  the  day.  These  data  were  reviewed  to  determine  the  cause  of  the 
discrepancy.  Each  satellite  pass  in  both  data  sets  was  examined  for  characteristics  that  adversely 
affect  quality,  such  as  large  multipath  content  and  discontinuities,  which  cause  the  differential 
phase  reference  level  from  phase-averaging  to  be  incorrect.  Short  passes  of  less  than  ninety 
minutes  also  yield  incorrect  reference  levels  when  phase-averaged.  The  Westford  differential 
group  delays  were  found  to  contain  some  very  large  multipath  associated  with  data  from 
elevations  below  twenty  degrees,  so  each  pass  was  edited  to  remove  low  elevation,  high 
multipath  sections.  The  Hanscom  data  were  edited  to  remove  high  multipath  sections.  Passes 
containing  discontinuities  were  segmented  into  separate  files,  with  pass  segments  less  than  ninety 
minutes  duration  being  deleted  from  either  data  set.  Recalibration  of  the  edited  data  sets 
produced  diurnal  curves  that  are  much  less  divergent  overall.  For  the  original  calibration,  the 
curves  are  divergent  from  0600  to  2000  IPP  local  time,  and  the  maximum  discrepancy  is  three 
TEC  units.  The  calibration  of  the  edited  files  resulted  in  curves  that  agree  to  within  one  TEC 
unit  for  most  of  the  day,  with  a  maximum  discrepancy  of  less  than  two  TEC  units  in  the  1600  to 
2000  IPP  local  time  period.  These  results  indicate  that  the  disagreement  in  the  diurnal  curves 
from  the  initial  calibration  is  the  result  of  low  elevation,  high  multipath,  discontinuous,  or  short 
data  segments. 

Data  previously  recorded  using  the  Real-Time  Monitor  (RTM)  system  obtained  from 
Applied  Research  Laboratories  (ARL)  at  the  University  of  Texas  at  Austin  were  reviewed,  to 
evaluate  a  problem  in  continuously  tracking  GPS  satellites.  The  recorded  values  indicate  that 
some  satellites  are  observed  throughout  their  period  of  visibility,  but  that  a  loss  of  lock  for  the 
phase  occurs  for  most  of  that  time.  This  problem  has  occurred  for  the  RTM  system  during  its 
deployment  at  Shemya,  Thule,  and  Otis,  but  appears  to  have  been  minimal  for  its  deployment  at 
Croughton.  Recommendations  were  obtained  from  ARL  personnel  for  techniques  in  further 
diagnosing  this  problem,  and  new  data  were  recorded.  An  additional  reference  file  was  generated 
in  conjunction  with  one  of  these  data  sets,  to  report  more  details  of  the  actual  receiver  data  and 
not  just  results  from  the  data-collection  program.  These  results  were  discussed  with  personnel 
from  ARL,  and  data  files  were  transferred  to  them  for  further  analysis.  Their  observation  was 
that,  when  the  loss  of  lock  in  satellite  tracking  occurred,  it  apparently  occurred  only  in  the  L2 
frequency.  Evaluation  of  this  situation  is  continuing. 

Procedures  were  developed  in  Interactive  Data  Language  (IDL)  for  the  display  of  TEC  maps 
based  on  data  from  one  GPS  receiver  station.  The  display  options  included  a  three-dimensional 
mesh  representation  and  a  color  contour  representation  of  equivalent  vertical  TEC  versus  latitude 
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and  local  time,  and  a  color  contour  representation  of  equivalent  vertical  TEC  on  a  global  map.  A 
three-dimensional  mesh  representation  for  equivalent  vertical  TEC  for  day  94-119  at  ARL  is 
displayed  in  Figure  2.  These  are  the  same  data  that  were  displayed  as  latitude  bands  in  Figure  1 
in  "Analysis  of  Ionospheric  Monitoring  System  (IMS)  Total  Electron  Content  (TEC)  Data  and 
Equatorial  Phase-Scintillation  Data"  [Secan  et  al,  1995]. 
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Figure  2.  Three-dimensional  mesh  representation  for  equivalent  vertical  TEC  versus  latitude  and 
local  time  at  the  Ionospheric  Penetration  Point  (IPP),  for  day  1 19  of  1994  (29  Apr  1994). 


2.2  Ionospheric  Measuring  System 

2.2.1  IMS  Companion  PCs.  A  set  of  Pentium  PC  systems  has  been  configured  for  each 
currently  scheduled  IMS  deployment,  for  data-acquisition  support  and  on-site  processing. 
Enhanced  communications  capabilities  and  recent  software  improvements  have  resolved  the 
earlier  data-acquisition  problems,  and  permitted  the  offloading  of  some  data-processing  stages 
onto  the  deployed  PC.  In  partieular,  the  One-Minute  data  extraction  from  the  IMS  archive  files 
now  occurs  in  near-real-time  as  these  files  are  transferred  from  the  IMS.  An  automated  tape¬ 
archiving  process  was  also  implemented  on  the  PC.  The  basic  roles  of  the  IMS  and  its 
companion  PC  are  displayed  in  Table  1. 
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Table  1.  Basic  functions  performed  by  the  IMS  and  their  companion  PCs. 


IMS  Function 

Companion  PC 

Data  collection 

High-speed  dialup  connection 

Data  validation 

Data  archiving 

Vertical  TEC  calculation 

Data  tabulation  for  display 

TELSI  transmission 

Calibration  support 

The  Otis  PC  experienced  a  hard-disk  failure  in  early  December  1995,  and  was  replaced 
during  a  planned  visit  to  Otis,  utilizing  another  Pentium  PC  that  had  been  configured  for 
deployment  with  the  Shemya  IMS.  Consequently,  a  new  Pentium  PC  was  configured  as  a 
replacement  for  deployment  with  the  Shemya  IMS.  A  similar  Pentium  PC  that  had  been 
configured  for  use  both  at  remote  IMS  sites  and  locally  as  a  data-acquisition  and  remote¬ 
monitoring  system  had  also  experienced  a  hard-disk  failure  in  early  November  1995.  This  disk 
was  replaced  without  difficulty,  but  the  warranty  period  had  expired  by  the  time  of  the  Otis  PC 
disk  failure,  so  a  disk  exchange  was  required.  The  situation  has  been  discussed  between  PLH 
personnel  and  the  disk  manufacturer,  and  there  is  a  likelihood  that  both  disks  could  have  been 
from  a  single  batch  that  had  defects. 

During  the  latter  part  of  February  1996,  the  Pentium  PC  system  that  was  deployed  with  the 
Croughton  IMS  for  data-acquisition  support  and  on-site  processing  experienced  a  number  of 
intermittent  interruptions  during  remote  operating  sessions  and  was  frequently  unresponsive  to 
remote  session  initiation  without  a  full  power  reset.  To  alleviate  this  problem,  and  at  the  same 
time  achieve  a  major  system  and  processing  software  upgrade,  the  Pentium  PC  that  had  been 
retrieved  from  Otis  in  December  1995  was  refurbished  with  a  new  hard  disk,  loaded  with  the 
most  recent  software,  tested,  and  shipped  to  Croughton  RAF,  UK,  as  a  replacement.  The  former 
Croughton  PC  was  then  shipped  back  to  PLH  for  examination  and  testing.  An  initial 
examination  of  this  PC  by  PLH  and  NWRA  personnel  revealed  a  failure  of  the  processor  chip 
cooling  fan,  which  was  replaced,  and  some  difficulties  with  the  network  board,  which  was  also 
replaced.  The  hard  disk  was  also  closely  examined,  given  the  previous  experience  with  similar 
disks  obtained  at  that  time.  The  replacement  PC  has  performed  well  at  Croughton  since  its 
installation,  although  sporadic  communications  problems  are  still  encountered. 

During  the  early  part  of  March  1996,  the  Pentium  PC  system  that  was  deployed  with  the 
Thule  IMS  for  data-acquisition  support  and  on-site  processing  was  recognized  as  requiring  a 
significant  software  upgrade,  particularly  with  regard  to  preliminary  software  versions 
implemented  with  an  expiration  date.  To  address  this  situation,  the  Pentium  PC  that  had  been 
shipped  from  Croughton  RAF,  UK,  in  February  1996  and  refurbished,  was  loaded  with  the  most 
recent  software,  tested,  and  shipped  to  Thule  Air  Base,  Greenland,  in  mid- April  1996  as  a 
replacement.  The  original  Thule  companion  PC  was  left  at  the  site  until  the  maintenance  visit  to 
Thule  in  late  June  1996. 

The  local  PC  used  to  monitor  the  remote  IMS  sites  experienced  a  brief  interruption  in 
service  when  the  fan  for  the  power  supply  failed,  causing  an  overheating  problem.  A  temporary 
remedy  was  implemented  until  a  new  power  supply  was  received  and  installed. 
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A  development  plan  has  been  formulated  to  implement  autonomous  bias  calibrations  at  the 
individual  IMS  sites,  utilizing  TEC  data  acquired  from  each  IMS  by  its  companion  PC  on  a  near- 
real-time  basis.  Issues  addressed  by  the  plan  include  data-quality  checking,  phase-discontinuity 
correction,  reliable  phase-averaging  calculations,  improved  bias  calculations,  and  implementation 
of  the  bias  corrections  on  the  IMS.  A  phased  implementation  is  planned,  both  to  monitor  the 
effects  of  automating  each  step  and  to  reduce  the  manual  workload  required  in  monitoring  each 
site  at  the  earliest  opportunities. 

To  expedite  on-line  data  acquisition  at  PLH  from  the  remote  PC  at  each  IMS  site,  a  new 
procedure  was  developed  and  tested  to  automate  the  initial  stages  of  the  IMS  data  extraction  and 
reformatting.  This  new  procedure  allows  the  number  of  telephone  connections  to  each  PC  to  be 
reduced.  The  same  procedure  was  uploaded  to  the  companion  PCs  at  Thule,  Croughton,  and 
Otis,  and  was  installed  on  the  companion  PC  for  Shemya  before  shipping. 

On-site,  autonomous  processing  capabilities  for  the  companion  PC  at  each  IMS  site  were 
augmented  by  development  of  a  daily  process  to  concatenate  the  15-minute  duration  pass  file 
segments  that  are  generated  in  near-real-time  in  association  with  the  data-transfer  process  from 
the  MS.  A  further  maintenance  automation  was  achieved  by  the  development  of  a  process  to 
delete  intermediate  data  files  more  than  three  days  old.  This  process  can  also  be  utilized  to  delete 
MS  archive  files  that  have  been  written  to  the  PC  backup  tape. 

The  program  that  performs  the  concatenation  of  the  15-minute  pass  file  segments  was 
enhanced  to  allow  more  flexibility  in  setting  segmenting  thresholds  and  to  improve  the  criteria 
used  in  the  concatenation  process. 

2.2.2  IMS  Procedures.  The  UNIX  scripts  that  were  previously  developed  for  data-file 
transfers  from  the  MS  to  its  companion  PC  were  adapted  for  installation  on  the  Thule  MS, 
which  was  deployed  at  Thule  Air  Base,  Greenland,  during  the  latter  part  of  August  1995.  Some 
of  the  revisions  were  required  for  site-specific  addressing  conventions,  while  most  of  the  others 
were  implemented  to  interact  properly  with  the  different  network  program  being  utilized  on  that 
and  subsequently  deployed  PCs.  Provisions  for  real-time  data  transfer  were  incorporated  into  the 
new  procedures,  and  these  have  worked  well  with  the  new  PC  ITTP  server.  These  UNIX  scripts 
have  also  been  augmented  to  require  less  operator  intervention  for  initialization  and  error 
conditions,  and  to  provide  more  diagnostic  logging  information. 

To  reduce  operator  maintenance  efforts  for  the  remote  MS  sites,  a  new  procedure  was 
developed,  tested,  and  uploaded  to  the  Otis  MS,  Croughton  MS,  and  Thule  MS  to  delete  data 
files  older  than  a  specified  number  of  days  (typically  five)  from  the  intermediate  data-archiving 
directory  allocated  to  operational  maintenance.  These  files  were  originally  maintained  as  part  of 
the  stopgap  procedure  developed  to  overcome  the  problems  with  the  original  MS  tape  archiving, 
and  are  currently  maintained  only  as  a  backup  to  the  near-real-time  data  transfer  to  the 
companion  PC  at  each  site. 

Coordinated  investigations  were  conducted  with  personnel  from  the  Charles  Stark  Draper 
Laboratory  (CSDL)  to  investigate  the  source  of  very  large  DGD  values  during  the  initial  minutes 
of  a  satellite  pass.  Data  segments  exhibiting  such  features  in  the  1 -minute  or  15-minute  sample 
averages  were  re-examined  at  the  original  2-Hz  data-sampling  rate,  including  the  data  quality  and 
warning  flags  and  signal  strength  as  well  as  the  measured  DGD  and  DCP .  It  was  found  that  non¬ 
zero  warning  flags  were  associated  with  extreme  and  irregular  variations  in  DGD,  so  CSDL 
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personnel  implemented  a  change  in  the  initial  data  collection  and  processing  stages  to  check  the 
appropriate  flags  before  utilizing  the  data  for  the  time-averaging.  A  secondary  elevation 
threshold  was  also  instituted,  so  that  data  samples  below  this  elevation  would  be  excluded  from 
the  time-averaging.  Both  of  these  changes  were  tested  on  the  IMS  at  PLH,  and  were  installed  on 
the  IMS  at  Otis,  Croughton,  and  Thule  when  satisfactory  test  results  were  achieved. 

2.2.3  Ghost  Satellites.  Further  investigations  into  the  IMS  "ghost"  satellites  (GPS  satellites 
that  are  spuriously  reported  by  the  IMS)  have  been  conducted.  These  investigations  included  the 
examination  of  data  stored  by  a  stand-alone  receiver  of  the  same  type  as  used  in  the  IMS,  a  time- 
occurrence  survey  for  "ghost"  occurrences  on  the  Otis  IMS,  a  survey  of  "ghost"  occurrences  for 
the  Croughton  IMS,  and  "ghost"  occurrences  associated  with  different  antennas. 

Data  collected  at  PLH  using  both  a  stand-alone  receiver  and  the  IMS  yielded  no  ghosts,  but 
in  neither  case  was  an  IMS  antenna  assembly  utilized,  because  no  operational  spare  assemblies 
were  available  locally.  A  new  Ashtech  receiver  was  installed  for  the  Otis  IMS  in  early 
November  1995,  but  examination  of  the  collected  data  still  showed  the  presence  of  ghosts.  An 
effort  was  coordinated  with  CSDL  and  PLH  personnel  to  evaluate  data  captured  directly  from  the 
Otis  IMS  receiver,  bypassing  the  normal  IMS  processing,  and  joint  analysis  of  this  period 
demonstrated.the  occurrence  of  ghosts  in  the  receiver  data  concurrent  with  those  appearing  in  the 
normal  IMS  processing.  The  procedures  for  acquiring  and  evaluating  GPS  ephemeris  data 
reported  by  the  IMS  were  considerably  enhanced  and  streamlined  in  order  to  pursue  this 
investigation,  because  the  ephemeris  data  have  proven  to  be  the  best  indicator  of  ghosts. 

The  RTM  notebook  PC  configured  for  GPS  data  collection  was  temporarily  installed  at  Otis 
ANGB  with  its  own  receiver  and  antenna,  in  the  same  vicinity  as  the  IMS  at  that  site.  During  the 
first  day  of  data  collection,  the  RTM  system  detected  no  ghosts,  while  the  IMS  continued 
detecting  ghosts.  The  antennas  for  the  IMS  and  the  RTM  system  were  exchanged  for  the  second 
day  of  data  collection,  and  no  ghosts  were  detected  by  the  IMS  for  that  configuration,  while  the 
RTM  system  did  detect  ghosts.  These  results  indicated  that  the  ghost  problem  was  not  associated 
with  the  site  environment,  but  was  strongly  linked  to  the  antenna. 

An  Ashtech  antenna  was  installed  at  Otis  on  the  roof  of  the  building  containing  the  IMS,  and 
was  connected  to  the  IMS  by  an  alternative  cabling  system.  Concurrently,  a  process  was 
developed  to  expedite  review  of  the  GPS  ephemeris  information  reported  by  the  MS,  to  enable 
the  detection  of  "ghost"  GPS  satellites.  This  system  configuration  was  examined  for  "ghosts"  for 
over  a  month  without  any  observed  occurrences,  except  on  one  day  when  the  data  appear  to  have 
been  contaminated  by  reports  from  the  previous  antenna. 

Difficulty  in  maintaining  a  stable  calibration  for  the  Otis  MS  after  the  installation  of  the 
roof  Ashtech  antenna  led  to  a  detailed  investigation  of  the  data  being  recorded  by  the  MS.  It 
was  determined  that  the  DGD  signals  reported  in  the  One-Minute  data  were  highly  variable  from 
day  to  day,  in  a  manner  inconsistent  with  the  degree  of  multipath  variation  normally  observed.  A 
number  of  diagnostic  evaluations  were  conducted  by  PLH  personnel,  including  changing  the 
antenna,  performing  an  RF  spectral  examination,  and  shortening  the  antenna  cable,  but  none  of 
these  resolved  the  problem.  Finally,  NWRA  and  PLH  personnel  installed  an  Ashtech  antenna  in 
the  MS  antenna  housing,  at  a  considerable  distance  from  the  MS  building,  and  the  problem 
appears  to  have  been  circumvented,  together  with  the  elimination  of  ghosts. 
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Two  further  experiments  were  performed  for  investigating  the  problem  of  "ghosts".  The 
original  IMS  Micropulse  antenna  that  was  shipped  to  CSDL  with  the  fifth  IMS  was  installed  at 
PLH  in  early  February  1996,  and  was  found  to  produce  "ghosts"  within  its  first  two  days  of 
operation.  This  antenna  was  installed  without  its  accompanying  housing.  An  Ashtech  antenna 
was  then  installed  in  the  IMS  antenna  housing  in  early  March  1996,  at  a  comparable  location  at 
PLH,  and  was  examined  using  the  same  procedures  earlier  employed  for  Otis,  without  the 
detection  of  any  "ghosts"  for  a  period  of  three  weeks. 

2.2.4  Operations.  Data  files  continue  to  be  processed,  reviewed,  and  archived  to  tape  at 
each  of  the  deployed  IMS  sites  at  Thule,  Greenland;  Croughton,  United  Kingdom;  and  Otis 
ANGB,  Massachusetts;  with  the  archive  tapes  being  shipped  to  PLH  for  cataloguing.  The 
development,  testing,  and  data-archiving  operations  of  the  PLH  IMS  and  its  companion  Pentium 
PC  were  discontinued  in  mid-June  1996,  with  the  shipment  of  those  systems  to  Eareckson  AFS, 
Alaska.  The  data-transfer  process  from  the  IMS  to  its  companion  PC  at  all  deployed  sites  has 
been  improved  to  ensure  that  all  data  files  generated  by  the  IMS  are  eventually  transferred  to  the 
PC,  even  if  the  PC  FTP  server  is  not  active  at  the  originally  scheduled  transfer  time. 

A  summary  log  is  being  maintained  for  the  IMS  at  Otis,  the  IMS  at  Croughton,  and  the  IMS 
at  Thule,  primarily  to  monitor  the  duration  of  operations  for  each  of  the  two  UNIX  computer 
systems  in  each  IMS.  The  cause  of  the  system  shutdown  is  also  recorded  in  this  log.  A  script  has 
been  developed  to  process  the  status-report  files  from  the  IMS  and  automatically  update  this 
summary  log.  Utilization  of  this  script,  in  conjunction  with  a  processor-identification  report  to 
the  on-site  system  log,  has  greatly  facilitated  this  log  maintenance. 

Otis.  The  IMS  at  Otis  had  been  experiencing  a  sporadic  problem  in  initializing  one  of  its  pair  of 
processors,  but  finally  encountered  a  situation  in  late  January  1996  where  neither  processor  could 
be  initialized,  disabling  the  entire  system.  Based  on  similar  symptoms  encountered  with  other 
IMS  processors  prior  to  their  SCSI  cabling  reconfiguration,  the  IMS  failure  at  Otis  was  diagnosed 
as  a  late  appearance  of  this  same  cabling  problem,  because  the  Otis  IMS  has  not  yet  been  cabled 
in  the  revised  configuration.  Rather  than  implement  a  full  cabling  reconfiguration,  however, 
with  the  associated  disassembly  and  reassembly  of  the  entire  equipment  rack,  only  a  partial 
cabling  reconfiguration  was  performed,  with  the  insertion  of  an  electronic  SCSI  cable  terminator. 
The  Otis  IMS  was  then  restored  to  operational  status. 

Croughton.  The  IMS  at  Croughton  RAF  Base  in  England  was  operational  until  20  July  1995,  by 
which  time  both  the  direct  dialup  connection  and  the  companion  PC  for  that  site  were  not 
operational.  The  direct  dialup  connections  were  restored  on  6  September  1995,  and  one  of  the 
new  Pentium  PC  systems  was  delivered  as  a  replacement  for  the  original  PC.  On-line  data  file- 
storage  procedures  were  temporarily  circumvented  on  the  IMS,  to  attain  minimal  operational 
status  of  the  IMS.  The  original  PC  has  been  returned  to  PLH  for  diagnosis  and  possible 
reconfiguration  as  a  spare.  Local  support  at  PLH  was  provided  to  PLH  personnel  working  at 
Croughton  during  the  re-installation  of  the  Netblazer,  installation  of  the  new  PC,  and  loading  and 
configuration  of  the  new  software  on  the  IMS  there. 

The  IMS  at  Croughton  RAF  Base  in  England  was  then  operating  in  a  stand-alone  mode  until 
15  November  1995,  although  it  was  accessible  by  direct  dialup  connection  and  through  its 
companion  PC.  However,  it  was  not  issuing  data  reports  to  its  network  connection.  On  15 
November  1995,  a  joint  effort  with  PLH  personnel  diagnosed  and  corrected  a  serial  port 
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parameter  setting,  and  data  reports  began  to  appear  at  50th  Weather  Squadron  (SOWS)  from  the 
Croughton  IMS.  Unfortunately,  the  stability  of  the  IMS  was  adversely  affected  by  the  additional 
communications  activity,  and  system  shutdowns  became  quite  frequent  (up  to  44  per  day). 
Consequently,  the  data  are  too  severely  fragmented  to  process  without  extensive  effort. 

To  assist  with  the  CSDL  analysis  of  the  frequent  system  shutdowns  of  the  Croughton  IMS,  a 
Full  Debug  mode  was  initiated  on  the  Croughton  IMS  by  NWRA  in  January  1996,  and  the 
resulting  log  files  were  retrieved  after  a  week  of  operation  in  this  mode.  These  files  were 
downloaded  from  the  Croughton  IMS  through  the  Croughton  companion  PC,  and  were  made 
available  to  CSDL  on  the  NWRA  FTP  server  system. 

The  operational  problems  for  the  Croughton  IMS  were  substantially  resolved  by  the  CSDL 
personnel  by  29  February  1996,  so  the  Croughton  IMS  is  now  regularly  transmitting  TEC  reports 
(TELSI  messages)  to  SOWS,  the  Croughton  PC  is  now  regularly  receiving  data  files  from  the 
MS,  and  the  software  update  associated  with  the  PC  exchange  in  March  1996  has  expanded  the 
near-real-time  and  automated  data  management  and  processing  capabilities. 

A  maintenance  visit  to  Croughton  RAF  was  performed  in  early  May  1996  to  change  the  GPS 
antenna  for  the  MS  there  for  alleviation  of  the  "ghost"  problem,  install  an  RF  filter  for  the  GPS 
receiver,  install  new  clock  batteries  and  UPS  batteries,  and  perform  general  system  maintenance. 
An  initial  calibration  was  performed  remotely  to  compensate  for  the  antenna  and  RF  filter 
installation,  and  was  implemented  as  just  a  change  in  the  receiver  bias  value.  A  subsequent 
calibration,  using  a  complete  day  of  data,  was  performed  to  adjust  both  the  satellite  and  receiver 
bias  values. 

Initial  examination  of  the  15-Minute  TEC  data  from  the  Croughton  MS  in  the  period 
following  the  antenna  change  and  associated  bias  calibration  indicated  that  another  calibration 
was  soon  required,  but  processing  of  the  One-Minute  data  to  derive  a  calibration  showed  much 
better  agreement  with  the  existing  calibration.  A  detailed  examination  of  the  One-Minute  data, 
and,  in  some  cases,  its  underlying  2-Hz  data,  validated  the  stability  in  the  DGD  multipath,  unlike 
an  earlier  situation  for  the  MS  at  Otis.  However,  the  multipath  amplitude  appeared  to  have 
increased  with  the  change  of  the  antenna,  and  this  increase  also  accentuated  a  provision  in  the 
initial  data  processing  in  which  a  small  set  of  2-Hz  data  samples  constitute  a  full  One-Minute 
sample,  resulting  in  a  "wild  point"  at  the  beginning  or  end  of  a  satellite  pass. 

A  further  evaluation  of  the  multipath  effect  on  the  15-Minute  TEC  data  reports  from  the 
Croughton  MS  was  conducted,  by  calculating  the  cumulative  phase-averaging  as  the  satellite 
pass  progressed,  rather  than  only  at  the  end  of  the  satellite  pass.  Because  of  the  long-period 
multipath,  the  cumulative  phase-averaging  adjustment  approaches  its  final  value  only 
asymptotically,  and  can  differ  from  this  value  by  2  to  5  TEC  units  over  much  of  the  satellite  pass. 
This  difference  then  appears  as  a  bias  error  for  most  of  the  15-minute  TEC  reports,  mimicking  a 
poor  calibration. 

Thule.  Data  accumulated  at  PLH  in  June  and  July  1995  during  the  testing  phase  for  the  MS  to 
be  deployed  at  Thule  Air  Base,  Greenland,  were  archived  to  tape  for  future  analysis. 

On-site  support  was  provided  for  the  Thule  MS  installation,  spanning  the  period  14  August 
1995  to  26  August  1995.  This  effort  included  proper  configuration  of  the  MS  rack,  diagnosis 
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for  a  faulty  antenna  for  GPS  signals,  and  general  performance  validation  and  optimization.  This 
effort  was  successfully  concluded  after  the  preliminary  evaluation  of  the  data  at  PLH. 

To  corroborate  the  Thule  IMS  data,  a  data  set  collected  by  the  installation  team  using  the 
RTM  system  was  also  processed.  Despite  being  only  a  partial  day  and  commencing  just  prior  to 
the  IMS  operation,  an  encouraging  general  consistency  was  obtained. 

The  IMS  at  Thule  was  operating  originally  in  a  stand-alone  mode,  with  no  data  reports,  but 
with  dialup  connections  and  communication  with  its  companion  PC.  In  preparation  for  network 
operations,  the  revised  IMS  software  that  was  delivered  to  PLH  in  September  1995  was  installed 
on  both  processors  of  the  Thule  IMS.  Portions  of  this  software  package  were  superseded  by 
software  installed  during  the  June  1996  maintenance  visit. 

A  maintenance  visit  to  Thule  Air  Base  was  performed  in  mid-June  1996  to  change  the  GPS 
antenna  for  the  IMS  there  for  alleviation  of  the  "ghost"  problem,  install  new  clock  batteries, 
deliver  new  UPS  batteries,  and  perform  general  system  maintenance.  A  thorough  investigation 
was  conducted  of  the  continued  failure  to  receive  TELSI  transmissions  from  the  Thule  IMS, 
including  serial  port  parameter  settings,  communications  links,  and  telephone  line  quality.  This 
problem  was  successfully  resolved,  and  TELSI  transmissions  have  since  been  received  regularly 
by  SOWS.  -  - 

During  the  latter  portion  of  the  Thule  maintenance  visit,  a  significant  problem  of  temperature 
variations  in  the  building  containing  the  IMS  was  addressed.  The  building  was  found  to  become 
excessively  warm  during  the  Arctic  24-hour  daylight,  so  the  transfer  and  installation  of  fans  and 
vents  from  another  building  were  arranged.  During  this  installation  period,  the  IMS  experienced 
low-temperature  shutdowns  due  to  a  snowstorm,  requiring  telephone  contacts  with  local 
technicians  to  restart  the  system. 

Hanscom/Shemya.  Data  accumulated  at  PLH  during  the  testing  phase  for  the  IMS  to  be  deployed 
at  Shemya,  Alaska,  were  processed,  reviewed,  and  archived  to  tape  for  future  analysis.  This  IMS 
and  its  companion  Pentium  PC  were  also  utilized  for  procedural-improvement  testing,  data 
quality  and  diagnostic  investigations,  and  software  testing. 

After  several  months  of  use  for  configuration  testing,  development,  and  diagnostic 
investigations,  the  hard  drive  for  the  companion  PC  at  PLH  experienced  a  severe  deterioration, 
and  was  replaced.  The  PC  system  was  then  reconfigured  in  its  original  role  as  the  companion  PC 
for  the  Shemya  IMS,  and  underwent  further  testing  for  about  a  month  before  being  shipped  for 
deployment.  This  was  the  fourth  original  hard  drive  of  this  group  of  six  PCs  to  fail. 
Replacement  hard  drives  have  been  obtained  from  the  vendor  in  all  cases. 

A  site  survey  was  conducted  at  Eareckson  AFS,  Shemya,  Alaska,  in  preparation  for  the  IMS 
to  be  installed  there.  Unfortunately,  the  RTM  computer  shipped  for  data  collection  and 
processing  for  the  survey  was  offloaded  at  the  wrong  site,  and  was  unavailable  for  the  entire 
planned  duration  of  the  visit.  A  computer  at  the  site,  which  had  previously  been  utilized  for  the 
Real-Time  Monitor  and  Scale  Factor  Generation  support,  was  reconfigured  for  data  collection 
using  the  new  receiver  and  antenna  shipped  for  the  site  survey,  utilizing  software  uploaded  by 
telephone  from  PLH.  Operation  of  this  system  was  monitored  both  on-site  and  remotely  for  the 
first  two  days,  after  which  an  RF  filter  was  installed  and  a  short  period  of  on-site  monitoring 
ensued.  Following  the  site  visit,  remote  monitoring  was  invoked,  to  retrieve  a  total  of  19  days  of 
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data,  of  which  nine  days  were  processed  and  six  days  extensively  examined.  Some  interference 
at  the  GPS  antenna  was  observed,  but  this  does  not  appear  to  be  associated  with  the  radar  at  the 
site.  A  more  detailed  discussion  of  the  site  survey  results  is  given  in  Appendix  A. 

CSDL.  The  fifth  MS,  designated  for  deployment  at  Diego  Garcia,  was  returned  to  CSDL  from 
SM-ALC  at  McClellan  Air  Force  Base,  Sacramento,  California,  and  was  reassembled  in  early 
February  1996  with  assistance  from  NWRA  personnel.  A  pair  of  personal  computers  was  also 
configured  to  accompany  the  MS  at  CSDL,  in  "site  companion"  and  "remote  dialup"  roles, 
analogous  to  the  network  operated  from  PLH.  The  remote  dialup  PC  at  CSDL  and  the 
companion  PC  at  Croughton  proved  to  be  essential  to  CSDL  in  installing  their  repaired  software 
on  the  Croughton  MS  in  late  February  1996. 

Data  from  the  fifth  MS,  taken  during  its  period  of  operation  in  Sacramento,  were  examined 
for  a  potential  problem  of  dual  occurrences  of  a  single  GPS  satellite  on  different  receiver 
channels.  This  situation  was  found  only  to  occur  when  two  distinct  satellite  passes  occurred 
during  the  day,  and  receiver  channel  switching  during  a  pass  did  not  occur  for  the  recorded  data. 

2.2.5  Software.  As  a  supplementary  study  for  the  DGD  variability  observed  during  antenna 
tests  at  Otis,  a  process  was  developed  to  examine  the  signal  to  noise  ratio  at  the  two  receiver 
frequencies  for  each  satellite  being  observed.  This  process  was  applied  to  the  MS  at  Otis  and, 
for  reference,  the  MS  at  PLH,  which  was  also  using  an  Ashtech  antenna  at  that  time.  The  signal 
patterns  were  quite  similar  for  the  two  Ashtech  antennas,  but  distinctly  different  from  the  pattern 
for  the  Micropulse  antenna  that  had  formerly  been  installed  at  Otis. 

Several  programs  were  modified  to  incorporate  the  satellite  and  receiver  biases  removed  by 
the  MS  pre-processing  stages  back  into  the  One-Minute  slant  TEC  measurements,  to  allow  for 
consistency  in  the  slant  TEC  measurements  across  calibration  updates.  The  resulting  biases  are 
then  calculated  on  ein  absolute,  rather  than  relative,  baseline,  and  the  calibration  value 
conversions  for  the  MS  are  somewhat  simplified. 

An  additional  plotting  program  has  been  developed  to  display  the  15-minute  interval  values 
for  mean  vertical  TEC,  maximum  vertical  TEC,  and  minimum  vertical  TEC,  as  extracted  from 
the  MS  data-archive  files.  These  values  are  equivalent  to  those  reported  to  SOWS  as  TELSI 
messages,  and  can  be  directly  used  to  monitor  the  data  quality  of  those  messages.  Similar 
displays  had  previously  been  generated  using  a  spreadsheet  program,  with  much  time-consuming 
preparation  and  formatting.  However,  the  original  display  technique  did  allow  the  demonstration 
of  a  simple  criterion  for  eliminating  wild  TEC  samples. 

This  plotting  program  for  displaying  the  15-minute  interval  values  was  extended  to  allow 
selection  of  latitude  and  longitude  ranges.  With  these  enhancements,  the  displayed  diurnal 
profiles  for  equivalent  vertical  TEC  can  be  used  to  evaluate  the  accuracy  of  the  calibration  being 
utilized  within  the  MS.  Procedures  have  been  developed  to  utilize  this  plotting  program  in  this 
manner,  greatly  facilitating  the  evaluation  of  the  calibration  accuracy  and  the  assessment  of  the 
need  for  re-calibration.  A  variation  of  this  plotting  program  was  developed  to  allow  the  display 
of  MS  TELSI  transmission  data  from  the  database  maintained  by  50WS.  This  allows  for  their 
review  of  data  in  a  format  comparable  to  that  used  at  PLH  with  the  NWRA  software.  A  further 
revision  of  this  program  was  incorporated  to  assign  the  contiguous  longitude  domain  (-180 
degrees  to  180  degrees  or  0  degrees  to  360  degrees)  more  appropriately  when  mapping 
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measurements  to  local  time  at  the  Ionospheric  Penetration  Point.  This  produces  a  more  accurate 
representation  of  the  diurnal  TEC  profile. 

2.2.6  Calibrations.  Data  files  were  retrieved  as  needed  from  the  individual  IMS  sites  and 
were  used  to  evaluate  the  performance  of  the  current  bias  definitions  for  the  IMS  and  to  calculate 
corrections  and  revised  bias  values  for  installation  on  the  IMS.  These  data  have  also  been 
reviewed  for  anomalous  and  spurious  TEC  measurements,  as  part  of  the  continued  assessment  of 
the  IMS  performance.  The  days  of  data  retrieved  for  bias  calibrations  at  the  deployed  sites  are 
listed  in  Table  2. 

An  evaluation  for  the  Otis  IMS  utilizing  data  for  11  September  1995  revealed  a  sudden 
change  in  the  DGD  values  of  about  6  TEC  units,  for  all  satellites  being  observed  at  5:50 
Universal  Time.  This  necessitated  a  bias  correction,  but  also  illustrated  a  potential  problem  in 
maintaining  the  calibration  of  the  IMS,  in  that  a  sudden  condition,  in  addition  to  the  expected 
slow  receiver  bias  drift,  must  be  accommodated. 


Table  2.  Dates  of  data  utilized  for  receiver  and  satellites  bias  calibrations. 


Otis 

Croughton 

Thule 

17  July  1995 

19  March  1996 

24  August  1995 

27  August  1995 

*19  May  1996 

21  April  1996 

12  September  1995 

15  October  1995 

23  October  1995 

29  October  1995 

14  November  1995 

*12  December  1995 

15  JanuEiry  1996 

*24  January  1996 

8  February  1996 

12  February  1996 

23  March  1996 

10  June  1996 

*20  June  1996 

*These  calibrations  were  required  by  an  antenna  change. 
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23  Single-Frequency  Ionospheric  Measurements.  The  Differential  Carrier  Phase  and 
Differential  Group  Delay  data  from  1994  PLH  GPS  measurements  were  used  in  a  simulation  of 
single-frequency  bias  determination.  The  slant  TEC  from  Differential  Carrier  Phase,  which  is 
only  a  measure  of  relative  slant  TEC,  was  input  to  the  single-frequency  calibration  process.  The 
resulting  diurnal  profile  for  equivalent  vertical  TEC  was  generally  within  two  TEC  units  of  that 
derived  from  phase-averaged  data,  which  utilizes  the  absolute  Differential  Group  Delay  as  a 
reference,  but  diverged  to  about  five  TEC  units  toward  the  end  of  the  day.  A  similar  experiment 
was  performed  using  slant  TEC  from  Differential  Group  Delay,  which  is  significantly 
contaminated  by  noise  and  multipath,  and  therefore  more  closely  simulates  the  single-frequency 
data  in  this  regard.  These  data  were  smoothed  using  a  sliding  average  process  to  decrease  noise 
and  multipath  and  were  then  input  to  the  calibration  process  for  single-frequency  data,  as 
individual  satellite  passes.  Despite  a  resultant  noise  level  of  about  one  TEC  unit,  quantitative 
agreement  with  the  dual-frequency  TEC  calculation  was  achieved  to  within  approximately  three 
TEC  units,  with  a  peak  diurnal  TEC  amplitude  of  only  about  15  TEC  units.  A  number  of 
enhancements  in  smoothing  the  slant  TEC  data  were  implemented  as  part  of  this  investigation. 

Data  collected  with  the  Trimble  Pathfinder  single-frequency  GPS  receiver  were  also  used  to 
study  the  adaptation  of  the  bias-determination  process  for  use  with  single-frequency  GPS 
measurements.  The  single-frequency  results  were  compared  to  slant  TEC  calculated  from  dual¬ 
frequency  differential  data,  and  the  values  were  found  to  diverge  in  some  cases.  Analysis  of  this 
problem  was  pursued,  addressing  round-off  errors  for  the  time  tag,  pseudo-range,  and  Doppler 
values,  but  the  discrepancy  was  not  resolved  in  this  initial  investigation.  Diurnal  profiles 
calculated  using  this  data  set  produced  only  rough  agreement  with  the  dual-frequency  results, 
even  with  significant  smoothing  of  the  slant  TEC. 

These  Trimble  Pathfinder  data  sets  were  subsequently  re-examined  in  an  attempt  to  improve 
the  calculation  for  slant  TEC  from  pseudo-range  and  Doppler  measurements,  thus  allowing  the 
possibility  of  calibration  for  equivalent  vertical  TEC  using  the  current  methods.  Direct 
comparison  of  slant  TEC  calculated  for  the  Pathfinder  data  collected  at  PLH  to  dual-frequency 
slant  TEC  collected  by  the  IMS  at  Otis  repeatedly  showed  a  divergence  with  time,  even  though 
both  systems  are  viewing  essentially  the  same  ionospheric  region.  The  nature  of  the  divergence 
indicated  a  possible  time  difference  between  the  pseudo-range  and  Doppler  data  samples  for  the 
Pathfinder,  and,  experimentally,  a  time  difference  of  0.004  seconds  was  observed  to  bring  many 
of  the  Pathfinder  and  IMS  satellite  passes  into  agreement,  although  significant  discrepancies 
remained  for  other  passes,  of  the  same  divergent  nature  as  previously.  A  calibration  of  the 
resulting  single-frequency  slant  TEC  data  produced  a  diurnal  ionospheric  TEC  profile  that 
differed  by  about  eight  TEC  units  from  that  derived  from  the  IMS  data. 

Single-frequency  GPS  data  collected  during  the  Chile  campaign  of  1994  were  reviewed,  in 
connection  with  visual  all-sky  images  also  produced  from  that  campaign.  With  the  assistance  of 
personnel  from  KEO  Consultants,  apparent  GPS  satellite  positions  during  periods  of  scintillation, 
as  determined  by  the  single-frequency  amplitude  variations,  were  coordinated  with  dark  regions 
of  630.0  nm  airglow,  which  are  associated  with  TEC  depletions.  Charts  of  the  observing 
geometry  were  constructed  for  a  number  of  instances  in  the  course  of  the  observations,  displaying 
the  vertical  propagation  of  disturbances  in  the  airglow  layer  and  the  ionosphere,  as  well  as  the 
lines-of-sight  from  the  observing  station  to  the  GPS  satellites  [Bishop  et  al,  1996].  An  item  that 
was  investigated  further  was  a  small  error  in  the  calculated  azimuths  and  elevations  for  GPS 
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satellites  at  the  Agua  Verde,  Chile,  site,  as  compared  to  calculations  from  an  independent  source. 
The  discrepancy  was  ultimately  traced  to  an  error  in  the  units  used  for  the  site  altitude.  In  the 
course  of  this  investigation,  the  programs  used  for  the  calculations  were  enhanced  for  greater 
versatility  in  handling  date  ranges  and  year-to-year  transitions,  and  in  preserving  the  numerical 
precision  of  the  acquired  data  values. 

Single-frequency  GPS  data  collected  at  PLH  as  test  data  for  the  forthcoming  fall  Chile 
campaign  were  reviewed,  to  evaluate  the  resolution  available  for  the  signal  strength  parameter. 
The  data  appeared  comparable  to  those  previously  obtained  by  the  single-frequency  Trimble 
Pathfinder  receiver,  which  has  been  successfully  deployed  for  measurement  of  scintillation 
occurrences,  so  further  utilization  of  data  from  this  new  receiver  is  planned.  This  is  a  significant 
extension  of  the  role  of  this  receiver,  which  was  originally  intended  only  to  provide  GPS  timing 
accuracy  to  another  measurement  system. 


3.  Real-Time  Equatorial  Scintillation  Analysis  and  Prediction 

Work  was  begun  during  this  year  under  Task  7  to  develop  techniques  and  software  that 
would  use  near-real-time  observations  of  scintillation  from  receivers  deployed  by  PL/GPIA  and 
of  the  topside  ionosphere  from  the  DMSP  SSIES  sensor  package  to  produce  short-term  predic¬ 
tions  of  scintillation  occurrence  in  a  specified  geographic  region.  The  software  developed  is  to 
be  part  of  the  Scintillation  Decision  Aid  (scinda)  program.  This  work  focused  on  four  activities: 

1.  Review  the  status  of  SSIES  data  processing  at  SOWS  to  determine  whether  further 
processing  will  be  required  to  prepare  the  data  for  the  analysis  technique  developed  by  P. 
Sultan  [Sultan,  1996]. 

2.  Establish  procedures  for  calculating  estimates  of  the  height-integrated  irregularity 
strength,  CkL,  from  the  scintillation  observations  and  implement  them  in  software. 

3.  Determine  how  best  to  incorporate  a  wide  range  of  ionospheric  measurements  into  the 
equatorial  CkL  model  in  wbmod. 

4.  Develop  software  that  implements  the  techniques  developed  for  incorporation  of  real¬ 
time  observations  and  generates  grid-output  files  of  ionospheric  irregularity  parameters 
and  of  S4  for  a  particular  scenario. 

3.1.  SSIES  Data.  The  objectives  of  this  subtask  were  to  determine  (1)  if  modifications  made  to 
the  SSIES  processing  software  by  NWRA  after  formally  delivering  the  code  to  Air  Weather 
Service  (AWS)  in  1987  had  been  implemented  as  reported  to  AWS,  and  (2)  if  the  one-second 
average  ion  densities  output  by  the  Scintillation  Meter  (SM)  processing  code  were  usable  in  P. 
Sultan's  analysis  algorithm.  Comparison  of  the  operational  software  used  at  SOWS  with  the  code 
used  at  NWRA  disclosed  that  several  changes  recommended  by  NWRA  had  not  been  imple¬ 
mented  in  the  SOWS  code.  Consequently,  updated  versions  of  four  subroutines  in  the  SSIES 
processing  code  (routines  SMPRC,  ELAMP,  RANGE,  and  ENDS  1 1)  again  were  provided  to  SOWS.  A 
new  routine,  rnganl,  was  also  provided  to  generate  a  simple  analysis  of  the  embedded  range 
flags  found  in  a  given  pass  which  can  be  used  to  establish  the  validity  of  a  look-up  table  used  by 
the  processing  code  to  translate  these  range  flags  to  settings  of  the  electrometer  and  wide-band 
ranging  electrometer  amplifiers.  Copies  of  these  codes  were  also  provided  to  Dr.  Fred  Rich 
(PL/GPSG). 
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Agreement  was  reached  on  the  format  of  processed  SSIES  SM  data  to  be  provided  NWRA 
by  SOWS  to  meet  the  second  objective  of  this  subtask.  NWRA  will  be  sent  data  from  the  F-13 
satellite  for  a  24-hour  period  to  perform  an  assessment  of  whether  any  pre-processing  of  the  data 
will  be  required  prior  to  passing  the  data  to  P.  Sultan's  analysis  algorithm. 

3.2  Convert  S4  to  CkL.  Software  was  developed  to  convert  observations  of  intensity 
scintillation  expressed  in  the  S4  scintillation  index  to  estimates  of  the  height-integrated 
irregularity  strength,  CkL.  This  software  was  based  on  similar  software  developed  for  AWS  as 
part  of  the  Ionospheric  Scintillation  Specification  and  Prediction  System  (ISSPS).  One  of  the 
ISSPS  programs,  GBCKL,  was  designed  to  take  phase  and  intensity  scintillation  observations  from 
modified  GPS  receivers  and  convert  them  to  estimates  of  CkL  [Secan  et  al,  1990].  The  code 
delivered  on  this  project,  s4CKL,  is  a  subset  of  the  algorithms  from  program  GBCKL.  Figures  3 
and  4  demonstrate  the  results  obtained  from  this  code  using  data  from  PL/GPIA  receivers  located 
at  Antofagasta,  Chile,  and  Ancon,  Pern.  These  figures  show  data  from  five  different  paths:  two 
VHF  paths  from  Antofagasta  westward  to  FLEETS AT-7  (first  panel  in  each  figure),  an  L-band 
path  from  Antofagasta  northward  to  GOES-8  (second  panel),  a  VHF  path  from  Antofagasta 
eastward  to  FLEETSAT-8  (third  panel),  and  a  VHF  path  from  Ancon  westward  to  FLEETS  AT-7 
(fourth  panel).  The  code  was  delivered  to  PL/GPIA  for  incorporation  into  the  SCINDA  program. 

3.3  Use  of  Real-Time  Observations.  Two  sources  of  real-time  observations  are  to  be 
incorporated  into  the  SCiNDA  program:  (1)  intensity  scintillation  observations  in  the  form  of  the 
S4  scintillation  index  from  three  stations  in  the  South  American  sector  (Ancon,  Peru; 
Antofagasta,  Chile;  and  Howard  APB,  Panama),  and  (2)  estimates  of  the  probability  that  post¬ 
sunset  plume  structures  will  form  based  on  analysis  of  data  from  the  SSIES  SM  sensor.  These 
data  are  to  be  used  to  establish  the  location  and  severity  (in  terms  of  irregularity  strength)  of  post¬ 
sunset  plume  structures  in  the  region  of  interest  (the  South  American  equatorial  sector  for  the 
purposes  of  this  study)  and  to  adjust  the  wbmod  climatology  where  no  plume  observations  are 
possible  based  on  observed  scintillation  levels.  In  the  division  of  responsibilities,  NWRA  was 
given  the  task  of  developing  algorithms  and  software  to  modify  the  WBMOD  climatology  to  match 
the  SSIES  analyses  and  any  available  S4  observations  and  to  use  this  modified  climatology  to 
build  gridded  fields  of  irregularity  and  scintillation  parameters  into  which  the  SCINDA  program 
will  place  discrete  plume  structures  based  on  models  and  analyses  developed  by  other  agencies. 

In  all,  there  are  three  types  of  inputs  available:  (1)  specifications  and  surrogate  measures  of 
general  solar  and  geophysical  conditions  (sunspot  number,  geomagnetic  indices,  season,  etc.),  (2) 
specifications  of  the  probability  that  depletion  plumes  will  form  in  the  post-sunset  equatorial 
ionosphere  from  analysis  of  DMSP  SSIES  data,  and  (3)  real-time  estimates  of  CkL  from  the 
PL/GPIA  receivers  in  the  South  American  sector.  If  only  the  various  indices  are  available,  the 
fields  output  by  the  software  described  in  the  next  section  are  based  solely  on  the  most  recent 
WBMOD  climatology  [Secan  and  Bussey,  1993, 1994].  If  real-time  observations  are  available,  this 
climatology  is  modified  to  reflect  the  observed  conditions  as  follows: 

1.  If  only  an  SSIES  analysis  is  available  and  is  determined  to  be  valid  for  the  time  and  location 
of  the  prediction  (as  discussed  later),  it  will  be  used  to  set  the  position  in  the  WBMOD 
climatological  distribution  of  CkL  to  either  the  plume  or  nonplume  populations  depending  on 
whether  the  analysis  value  generated  was  above  or  below  0.5,  respectively.  All  spatial  and 
temporal  variations  will  be  derived  from  the  underlying  climatology. 
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Figure  3.  Examples  of  the  S4  intensity-scintillation  index  observed  at  Antofagasta,  Chile,  and 
Ancon,  Peru,  on  four  VHF  and  one  L-band  propagation  path.  The  vertical  dashed  and  dotted 
lines  indicate  times  of  E-  and  F-region  sunset,  respectively,  for  ionospheric  penetration  at 
350  and  800  km  altitudes. 
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2.  If  CkL  values  are  input,  they  will  be  used  to  adjust  the  latitude  variation  of  CkL  in  the 
regions  outside  the  real-time  analysis  region  (defined  as  that  region  within  which  the  scinda 
code  will  be  placing  plume  structures  based  on  its  analysis  of  the  real-time  data).  Inside  the 
real-time  analysis  region,  CkL  will  be  set  to  the  nonplume  CkL  value,  which  is  either 
explicitly  input  to  the  analysis  or  derived  from  the  nonplume  WBMOD  population. 

Details  of  the  use  of  each  of  these  two  types  of  real-time  inputs  follow. 

3.3.1  SSIES  Analyses.  Two  issues  needed  to  be  resolved  in  determining  how  to  use  P. 
Sultan's  SSIES  analysis  in  the  real-time  update  process:  how  to  modify  the  output  fields  based 
on  the  analysis  (at  this  point  a  simple  0.0  or  1.0),  and  how  far  in  time  and  space  to  extrapolate  the 
analysis.  The  analysis  is  used  to  select  which  of  the  two  populations  in  the  log(CkL)  distribution 
function  to  use  in  generating  the  output  CkL  fields.  As  stated  earlier,  if  the  input  analysis  is  < 
0.5,  the  CkL  value  representative  of  the  non-plume  population  is  used;  if  the  analysis  is  >  0.5,  the 
value  representative  of  the  plume  population  is  used.  This  is  implemented  by  limiting  the 
distribution  function  to  a  single  Gaussian  distribution,  setting  the  log(CkL)  value  at  the  peak  of 
this  distribution  to  either  the  non-plume  or  plume  value  generated  by  the  rest  of  the  model,  and 
setting  the  percentile  to  use  in  generating  CkL  from  the  distribution  to  50%.  Thus,  the  analysis  is 
an  "on-off  switch"  that  will  control  whether  the  climatology  sections  of  the  output  field  are  based 
on  the  plume  or  non-plume  distributions. 

Extrapolating  the  results  of  the  SSIES  analysis  in  longitude  is  complicated  by  the  fact  that 
conditions  affecting  the  possible  generation  of  plume  structures  vary  with  longitude.  Thus,  while 
an  SSIES  analysis  at  one  longitude  might  indicate  that  conditions  are  good  for  plume  generation, 
this  might  not  be  the  case  at  longitudes  not  too  far  removed  from  the  observation  longitude,  due 
to  significant  changes  in  factors  that  affect  plume  growth.  In  particular,  the  longitude  variation 
of  the  seasonal  modulation  of  plume  generation  in  wbmod  is  based  on  a  hypothesis  put  forward 
in  Tsunoda  [1985]  that  plume  generation  will  be  most  likely  at  those  times  of  year  when  the 
sunset  terminator  is  aligned  with  the  local  geomagnetic  meridian.  In  addition,  recent  modeling 
work  (such  as  in  Maruyama  [1988]  and  Kelley  and  Maruyama  [1992])  suggests  that  the 
component  of  meridional  neutral  wind  along  the  geomagnetic  meridian  can  have  a  "braking" 
effect  on  the  growth  of  plumes.  This  will  also  vary  in  some  way  with  the  local  geomagnetic 
declination  angle  near  the  equator.  Given  this,  we  have  decided  to  permit  only  limited 
extrapolation  of  SSIES  analyses  in  longitude  sectors  where  the  geomagnetic  declination  angle 
varies  significantly  with  longitude  and  between  sectors,  and  to  permit  unlimited  extrapolation  in 
sectors  where  the  declination  is  fairly  constant  in  longitude. 

Figure  5  illustrates  this  point  and  shows  the  division  of  the  equatorial  region  into  six  longi¬ 
tude  sectors.  Unlimited  extrapolation  is  permitted  in  sectors  1,3,  and  5;  extrapolation  is  permit¬ 
ted  by  up  to  15°  in  longitude  in  sectors  2,  4,  and  6;  and  extrapolation  of  up  to  5°  in  longitude  is 
permitted  from  one  sector  to  the  next. 
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Longitude  Variation  of  Equatorial  Parameters 


Figure  5.  Longitude  variation  of  the  apex  (dip)  equator  (dashed  line)  and  the  magnetic 
declination  at  the  equator  (solid  line).  The  heavy  vertical  lines  indicate  boundaries  between 
the  six  longitude  sectors  used  in  the  SSIES  analysis. 

3.3.2  CkL  Observations.  The  use  of  the  CkL  observations  is  more  complex  than  the  use  of 
the  SSIES  analyses,  and  is  less  general  in  that  it  is  tailored  so  that  it  expects  the  inputs  to  come 
from  a  particular  set  of  locations  (in  geomagnetic  latitude).  In  its  current  implementation,  it 
expects  to  have  observations  from  an  equatorial  station  near  the  dip  equator  (Ancon,  Peru),  an 
equatorial  station  near  to  and  equatorward  of  the  anomaly  crest  region  (Antofagasta,  Chile),  and  a 
mid-latitude  station  near  to  and  poleward  of  the  anomaly  crest  region  (Howard  AFB,  Panama). 
The  program  looks  for  observations  at  geomagnetic  latitudes  near  to  +2°  (Ancon),  -9° 
(Antofagasta),  and  +20°  (Howard  AFB).  (In  this  context,  "near"  is  within  ±3°  latitude.)  These 
data  are  used  to  scale  the  latitude  variation  of  CkL  in  the  sections  of  the  grid  that  are  outside  the 
real-time  analysis  region  (i.e.,  at  those  grid  points  where  the  real-time  analysis  flag  is  zero). 

The  algorithm  is  expecting  that  the  CkL  observations  provided  by  the  SCINDA  program  are 
the  characteristic  CkL  values  for  the  time  indicated  on  the  input.  They  are  used  to  set  the 
maximum  CkL  in  the  post-sunset  region  at  the  equator  and  at  the  anomaly  crest.  The  program 
divides  the  inputs  into  day  and  night  observations  (based  on  the  time-past-sunset  time  used  in 
wbmod)  and  into  equatorial  and  near-crest  observations.  In  each  latitude  regime,  the  maximum 
nighttime  CkL  is  selected  from  the  inputs  and  is  used  as  the  maximum  post-sunset  value.  The 
same  is  done  with  the  daytime  values. 

The  following  algorithms  are  used,  depending  on  what  data  are  available. 
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1.  If  daytime  equatorial  values  are  available,  set  the  daytime  CkL  to  the  average  of  the  two 
equatorial  stations. 

2.  If  nighttime  values  are  available  from  both  equatorial  stations,  adjust  the  CkL  levels  at  the 
equator  and  at  the  anomaly  crest  and  the  half- width  of  the  transition  function  between  the  peak  of 
the  crest  and  the  equator.  If  this  analysis  fails,  the  average  difference  in  log(CkL)  between  the 
observations  and  the  model  values  are  used  to  scale  the  latitude  variation  as  an  additive  adjust¬ 
ment  to  both  the  equatorial  and  crest  maximum  values. 

3.  If  a  nighttime  value  is  available  from  only  one  equatorial  station  (Ancon  or  Antofagasta),  the 
difference  in  log(CkL)  between  the  observation  and  the  model  value  is  used  as  an  additive 
adjustment  to  both  the  equatorial  and  crest  maximum  values. 

4.  If  a  nighttime  value  is  available  from  the  mid-latitude,  near-crest  station  (Howard  AFB),  it  is 
used  to  set  the  transition  half-width  from  the  peak  of  the  anomaly  crest  into  the  mid-latitude 
ionosphere. 

In  all  cases,  the  time  variation  both  prior  to  and  after  the  post-sunset  peaks  is  controlled  by  the 
diurnal  model  from  wbmod. 

It  is  important  to  note  that  the  use  of  ground-based  CkL  measurements  is,  in  the  current 
implementation,  not  generally  applicable  to  any  set  of  observations  from  any  location  or  set  of 
locations.  Two  constraints  have  driven  the  decision  to  implement  to  a  specific  set  of  inputs: 
limited  resources  for  the  development  effort  and  limited  spatial  coverage  by  the  planned  ground- 
based  observing  network.  The  first  constraint  is  self-explanatory  -  developing  a  general  method¬ 
ology  that  is  robust  in  all  situations  is  far  more  costly  in  development  time  (and  in  testing  and 
debugging  the  implemented  code)  than  developing  one  tailored  to  a  specific  set  of  inputs  and 
situations.  We  have,  however,  striven  to  implement  the  codes  in  program  IRRGRID  so  that  future 
upgrades  to  more  general  capabilities  are  straightforward.  The  second  constraint  has  to  do  with 
the  latitude  spacing  of  the  expected  observation  set  (Ancon,  Antofagasta,  and  Howard)  and  the 
latitudinal  structure  of  the  equatorial  region. 

Figure  6  shows  the  latitude  variation  of  log(CkL)  from  the  present  WBMOD  for  the  time  of 
maximum  scintillation  activity  (roughly  an  hour  after  sunset)  near  solar  maximum.  The  vertical 
lines  indicate  the  latitudes  (solid  lines)  and  corresponding  conjugate  latitudes  (dashed  lines)  for 
each  of  the  three  stations  that  will  be  collecting  data.  While  it  is  arguable  whether  the  latimde 
variation  will  look  exactly  like  this,  the  general  distribution  of  a  peak  located  at  the  equatorial 
anomaly,  dropping  off  rapidly  into  mid-latitudes  and  more  slowly  towards  the  equator,  is  a 
reasonable  one.  The  point  to  be  made  here  is  that  while  we  may  be  able  to  determine  that  there  is 
enhanced  scintillation  levels  at  the  peaks  from  the  measurements  made  at  Antofagasta,  it  will  be 
impossible  with  these  data  to  (a)  specify  the  latitude  location  of  the  peak  and  (b)  specify  the 
maximum  log(CkL)  at  the  peak.  In  the  sense  of  attempting  to  fit  a  model  to  a  set  of  observations, 
this  is  a  classic  underdetermined,  or  undersampled,  problem. 
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Latitude  Variation  of  log(CkL)  [Model] 
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Figure  6.  Latitude  variation  of  log(CkL)  across  the  geomagnetic  equator  for  solar  maximum 
conditions  in  the  post-sunset  local-time  sector.  Vertical  solid  lines  indicate  the  latitudes  at 
which  scintillation  observations  will  be  made,  and  vertical  dashed  lines  indicate  the  corre¬ 
sponding  conjugate  latitudes. 

A  typical  approach  to  solving  such  problems  is  to  make  use  of  as  much  a  priori  information 
as  possible  to  constrain  the  problem  so  as  to  render  it  tractable.  In  our  case,  we  have  chosen  to 
fix  the  location  of  the  latitude  peaks  at  the  wbmod  values  of  ±16°  geomagnetic  latitude  and  to 
limit  the  value  of  log(CkL)  at  the  peak  to  a  maximum  value  of  36.5  (CkL  =  3.16x10^^).  We  then 
use  the  information  from  the  stations  to  specify  conditions  at/near  the  geomagnetic  equator 
(Ancon),  near  the  anomaly  crest  on  the  equatorward  side  of  the  peak  (Antofagasta),  and  near  the 
anomaly  crest  on  the  mid-latitude  side  of  the  peak  (Howard).  The  measured  CkL  values  are  then 
used  to  adjust  the  model  values  for  log(CkL)  at  the  equator  and  the  peak  (cross-equator  symmetry 
is  assumed)  and  the  transition  half-widths  of  the  Gaussian  functions  used  to  model  the  latitude 
variation  at  the  peaks. 

A  major  upgrade  to  this  analysis  would  be  possible,  given  data  to  provide  better  resolution  of 
the  latitude  variation.  Potential  candidates  are  the  latitude  variation  of  TEC  through  the  area  of 
interest  output  from  a  prism  analysis  or  direct  observations  of  TEC  and,  if  possible,  scintillation 
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from  a  low-altitude  polar-orbiting  satellite.  It  would  be  straightforward,  though  not  trivial,  to  add 
the  capability  to  use  this  information  in  the  IRRGRID  program,  but  it  would  require  a  bit  of 
development  work  "up  front"  to  determine  how  best  to  use  observations  of  the  latitude  variation 
of  TEC  to  model  the  expected  latitude  variation  of  scintillation  in  the  post-sunset  equatorial 
region. 

3.4  WBMGRID  Software.  The  algorithms  described  in  the  previous  section  were  implemented  in 
a  set  of  four  computer  programs  collectively  named  wbmgrid.  The  four  programs  have  a 
simplified  user  interface,  which  reads  inputs  from  a  single  ASCH-format  file  that  can  be 
constructed  either  manually  via  a  text  editor  or  automatically  by  a  more  sophisticated  graphical 
user  interface  (GUI)  program.  Functionally,  the  WBMGRID  programs  (1)  define  a  grid  of 
geographic  locations  that  will  form  one  end  of  a  set  of  ground-to-geostationary-orbit  ray  paths 
(program  LLGRID),  (2)  calculate  various  geometry-related  parameters  used  in  the  scintillation 
calculations  along  each  ray  path  (program  GEOMGRID),  (3)  calculate  eight  ionospheric  plasma- 
density-irregulaiity  parameters  for  each  ray  path  based  on  the  WBMOD  climatology  updated  with 
real-time  observations  (program  krgrid),  and  (4)  calculate  the  S4  intensity-scintillation  index 
along  each  ray  path  (program  s4grid).  Aside  from  software  design  considerations,  the  functions 
performed  byjhe  wbmgrid  suite  were  divided  among  several  programs  for  three  reasons:  (1)  to 
make  definition  of  the  grid  on  which  the  calculations  are  made  independent  of  all  other 
calculations  (program  LLGRID),  (2)  to  isolate  CPU-intensive  calculations  that  need  be  done  only 
once  for  a  given  scenario  (program  geomgrid),  and  (3)  to  separate  generation  of  the  ionosphere 
(program  irrgrid)  from  the  propagation  calculations  (program  s4grid)  to  permit  other  programs 
to  alter  the  ionospheric  parameters  (primarily  CkL)  based  on  analysis  of  data  not  available  to  or 
usable  by  program  irrgrid.  [Note:  A  User's  Manual  has  been  written  for  the  wbmgrid  codes 
and  is  included  as  Appendix  B  to  this  report.  Details  such  as  input-data  and  file  formats  are 
provided  there.  The  discussion  in  the  remainder  of  this  section  will  focus  on  design  issues  and 
on  general  use  of  this  suite.] 

Figure  7  shows  the  flow  of  information  within  the  wbmgrid  system  for  a  sample 
implementation  within  the  scinda  framework.  In  this  implementation,  all  interaction  between 
the  WBMGRID  programs  and  the  user  are  through  the  sciNDA  interface.  The  scinda  interface  will 
interact  with  the  user  (a  SOWS  forecaster)  to  determine  the  parameters  of  a  given  run.  It  then 
obtains  the  necessary  data  from  the  SOWS  database  system  and,  if  data  are  available,  runs  the 
Sultan  analysis  of  the  SSIES  SM  data  and  generates  the  necessary  CkL  values  from  the  S4 
observations  made  at  Antofagasta,  Ancon,  and  Howard  AFB.  This  information  is  used  to 
generate  the  (ASCH-format)  inputs  file  for  the  WBMGRID  suite  (see  Appendix  B  for  details)  that 
defines  which  of  the  programs  are  to  run  and  provides  the  inputs  necessary  for  each  program 
(shown  in  Figure  7  as  file  wbminputs.dat).  Assuming  that  the  codes  are  running  on  a  Unix 
system,  SCINDA  then  starts  a  shell  script  that  runs  the  various  WBMGRID  programs. 

If  the  user  has  defined  a  new  scenario  (a  different  grid  or  satellite  location),  programs  LLGRID 
and  GEOMGRID  will  need  to  be  run  first  to  build  the  grid-definition  file  (shown  in  Figure  7  as  file 
grid.bin)  and  the  two  geometry  grid  files  (files  geom.bin  and  eqgeom.bin).  Program  LLGRID  will 
define  the  grid  used  by  the  other  three  programs  either  from  specifications  of  the  boundary  and 
spacing  of  the  grid  in  the  inputs  file  or  as  an  explicitly  defined  grid  (one  entry  per  grid-point  lo¬ 
cation)  in  an  optional  (ASCH-format)  input  file  (file  grddef.dat).  If  the  user  has  requested  that  a 
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Figure  7.  Flow  diagram  of  the  WBMGRID  software  in  a  sample  implementation  as  part  of  the 
SCINDA  system.  Shaded  programs  and  output  files  need  be  run  only  if  the  scenario  geometry 
changes  {le.,  different  grid,  different  satellite  location).  Dashed  items  are  optional. 

previously  defined  scenario  be  used  (i.e.,  one  for  which  files  grid.bin,  geom.bin,  and  eqgeom.bin 
have  been  built  and  saved),  then  programs  LLGRID  and  GEOMGRID  need  not  be  run. 


The  next  step  in  processing  is  to  run  program  IRRGRID  to  build  the  file  containing  the 
parameters  that  define  ionospheric  plasma-density  irregularities  for  the  propagation  calculation 
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(file  irr.bin).  An  optional  output  from  this  program,  controlled  by  flags  in  the  inputs  file,  is  an 
(ASCn-format)  output  file  that  contains  the  latitude  profile  of  log(CkL)  based  on  the  other  inputs 
to  the  IRRGRID  program  (file  latfun.dat).  These  two  files  (irr.bin  and  latfun.dat)  can  then  be  read 
by  the  scinda  program  for  the  next  step,  which  is  to  add  the  effects  of  discrete  plume  structures 
to  the  predicted  CkL  grid.  The  updated  grid  of  irregularity  parameters  can  then  be  output  to  a  file 
with  the  same  format  as  irr.bin  (file  irr_pl.bin). 

The  final  processing  within  the  WBMGRID  suite  is  to  mn  program  s4grid  to  calculate  S4  for 
each  grid  point  based  either  on  the  grid  of  irregularity  parameters  generated  by  program  iRRGRiD 
or  by  the  modified  file  built  by  SCINDA.  The  file  built  by  s4grid  (s4.bin)  can  then  be  reformatted 
as  necessary  by  scinda  to  generate  the  final  product  for  the  end  customer  (AFSATCOM  in  this 
example  implementation). 

In  the  operations  scenario  just  presented,  program  scinda  would  start  the  shell  script  that 
runs  the  WBMGRID  programs  twice.  In  the  first  run,  programs  LLGRID  and  GEOMGRID  would  be 
run  if  necessary,  and  program  IRRGRID  would  be  run  to  build  the  file  of  irregularity  parameters. 
Program  s4grid  would  not  be  run  at  this  time,  which  is  accomplished  by  disabling  the  program 
via  a  flag  in  the  inputs  file  (see  Appendix  B).  (Note:  If  it  is  not  necessary  to  run  LLGRID  and 
GEOMGRID,  these  are  disabled  in  similar  fashion.)  When  scinda  has  completed  its  update  to  the 
irregularity-parameter  grid,  the  shell  script  is  remn  with  a  new  inputs  file  that  has  the  run  flags 
for  all  programs  except  s4GRID  disabled,  ff  the  user  desires  that  grids  be  generated  for  a  series  of 
times,  this  series  of  operations  is  repeated  for  each  time  desired.  The  files  built  for  the  different 
times  can  be  differentiated  by  using  the  valid  date/time  in  the  name  of  each  file  (input  and  output 
file  names  are  specified  to  each  program  in  the  inputs  file  -  see  Appendix  B). 

All  the  code  in  the  WBMGRID  suite  is  written  in  FORTRAN  77  with  a  minimal  number  of 
extensions  to  the  ANSI  standard.  All  four  programs  have  been  compiled  and  run  on  Unix  (Sun 
workstation)  and  Windows  (MS  Windows  3.11)  operating  systems.  The  inputs  file  uses  a 
NAMELIST-like  protocol  and  grammar,  but  is  controlled  by  a  library  of  routines  that  are 
completely  portable  between  compilers  (which  NAMELIST  is  not). 

The  size  (lines  of  code  and  executable  size)  and  run  times  (CPU)  for  each  of  the  four 
WBMGRID  programs  are  given  in  Table  3.  These  codes  were  compiled  (using  -03  optimization) 
and  run  on  a  Sun  UltraSPARC  140  workstation  (Solaris  2.5)  on  a  1°  by  1°  latitude/longitude  grid 
centered  on  (0.0°  N,  275 .0°E)  with  a  minimum  elevation  of  10°  and  north  and  south  latitude 
limits  of  60°.  The  resulting  grid  contained  a  total  of  16,027  grid  points  (10,985  in  the  equatorial 
region  which  require  calculation  of  the  equatorial  geometry  parameter  in  file  eqgeom.bin).  The 
inputs  for  program  irrgrid  from  the  inputs  file  for  this  run  are  listed  in  Figure  8.  These  statistics 
are  for  the  initial-release  version  (Version  0.00)  of  these  codes  dated  11  June  1996.  In 
benchmark  tests,  we  have  established  that  a  Silicon  Graphics  Indigo  with  a  150  MHz  440  CPU  is 
slower  than  a  Sun  UltraSPARC  140  by  a  factor  of  0.5  (SGI  times  =  2.0  x  Sun  times).  The  sizes 
of  the  various  binary  files  generated  in  this  run  are  listed  in  Table  4. 
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-  Environment  Information  - 

Date  =  960320 
Time  =  0200 
FIO  =  120.0 
Kp  =  3.0 

Percentile  =  90.0 

-  R/T  Data  (from  analyses)  - 

RT_Longitude_Limits  =  260.0  305.0 
Analysis_Longitude  =  280.0 
—  SSIES  Analysis  Results 
SSIES_DateTime  =960320  013453 
SSIES_Kp  =4.0 
SSIES_Longitude  =  305.0 
SSIES_Analysis  =  0.75 
—  CkL  Observations 
NonPlume_CkL  =  1.32E29 
CkL_Observations_Table 
960302  1211  -14.35  225.15  1.52E33 
960302  1212  15.35  226.15  2.62E33 

--  960302  1213  -2.35  227.15  3.72E33 

END_OF_TABLE 

-  CkL  Latitude  Function  Output  File  - 

CkL_Latitude_File  =  lckl_v_lat.dat 

Figure  8.  Inputs  to  program  IRRGRID  for  the  test  run  summarized  in  Table  3. 


Table  3.  WBMGRID  suite  program  statistics. 


Program 

Lines 

Size 

Run  Time  (sec) 

LLGRID 

3,427 

109  kB 

<1 

GEOMGRID 

5,924 

144  kB 

57 

IRRGRID 

13,145 

253  kB 

4 

s4grid 

3,720 

111  kB 

<1 

Table  4.  WBMGRID  suite  file  sizes  (test  example). 

File 

Size  (kB) 

grid.bin 

454 

geom.bin 

1,297 

eqgeom.bin 

711 

irr.bin 

584 

s4.bin 

65 
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Appendix  A:  Initial  Shemya  GPS  Receiver/Radar  Interference  Summary 

Abstract 

*  Site  visit  indicated  presence  of  interference  during  radar  operation. 

*  RF  filter  installation  appeared  to  reduce  interference. 

*  Test  equipment  was  left  operating,  with  remote  dialup  access  for  extension  of  study  (especially 
with  RF  filter). 

*  Observed  phenomena: 

Large,  but  stable,  multipath  at  low  elevations. 

Pulse  trains  in  the  Differential  Group  Delay,  sometimes  correlated  with  radar  operations. 

Spikes  in  the  Differential  Group  Delay,  with  no  apparent  correlation  among  satellites  or 
with  radar  operations. 

Background  This  initial  review  consisted  of  two  days  of  operation  of  the  GPS  receiver  system 
without  an  RF  filter  (3-Apr-96,  4-Apr-96),  and  four  subsequent  (but  not  successive)  days  with  a 
dual-band  bandpass  filter  (5-Apr-96,  7-Apr-96,  8-Apr-96,  9-Apr-96).  The  coverage  for  each  of 
the  days  was  not  necessarily  complete  over  time  or  observable  GPS  satellites,  but  is  a  substantial 
portion  of  the  available  GPS  observability.  The  first  three  days  of  this  survey  constituted  the 
Preliminary  Shemya  Site  Study,  which  was  performed  during  and  immediately  following  the  test 
equipment  installation  visit  to  Shemya  (Eareckson)  in  April  1996,  while  further  days  of  data  were 
retrieved  and  processed  subsequent  to  the  site  visit,  using  the  equipment  and  software  established 
at  the  radar  site  during  the  visit. 

Noise  bursts  The  predominant  effect  seen  during  periods  of  radar  operation  without  a  receiver 
RF  filter  was  a  set  of  noise  bursts  in  the  Differential  Group  Delay  (DGD),  straddling  the  stated 
radar  test  period  (presumably  due  to  the  warm-up  period  for  the  radar).  The  amplitude  of  these 
bursts  ranged  from  about  20  TEC  units  to  about  100  TEC  units,  with  different  amplitudes  for 
different  satellites,  even  during  the  same  radar  test. 

With  the  installation  of  the  RF  filter,  effects  were  still  observed  in  the  DGD  signals  during 
radar  tests,  but  these  appeared  as  distinct  pulse  trains,  ranging  in  amplitude  from  20  TEC  units  to 
100  TEC  units,  with  a  pulse  interval  of  about  3  to  10  minutes.  However,  these  pulses  did  not 
appear  on  all  satellites,  and  had  different  amplitudes  and  different  numbers  of  pulses  for  different 
satellites  even  during  a  single  radar  test  event.  It  is  not  even  certain  that  the  individual  pulses  are 
coincident  for  different  satellites. 

It  was  also  noted  that  a  pulse-train  interference  effect  was  observed  on  occasions  when  there 
was  no  radar  activity  reported  to  us.  These  were  basically  of  the  same  nature  as  those  cases 
where  the  radar  was  known  to  be  operational,  except  that  the  pulse  amplitudes  were  sometimes 
observed  to  be  as  large  as  about  200  TEC  units. 
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For  reference,  the  radar  operation  times  (UT)  known  to  us  are  listed  for  each  of  the  relevant 
days. 


3 -Apr- 9 6 
3:47 
9:12 
21:15 


4-Apr-96  5-Apr-96 

8:48  10:05 

10:29  20:26 


7-Apr-96  8-Apr-96 

9:16  8:51 

21:18  19:37 

20:53 


9 -Apr- 9 6 
8:27 
10:08 
20:29 


The  periods  marked  by  noise  bursts  or  pulse  trains  with  no  known  radar  operations  are  listed 
below.  The  times  are  also  Universal  Time,  but  are  only  approximate  because  the  observed  events 
are  not  instantaneous. 

3-Apr-96  4-Apr-96  5-Apr-96  7-Apr-96  8-Apr-96  9-Apr-96 

16:20  22:30-  0:30 

17;10  24:00  3:15 

4:20-5:30 


Based  upon  discussions  with  on-site  personnel,  these  pulse  train  features  are  unlikely  to  be 
associated  with  the  radar  operation,  but  rather  arise  from  ancillary  equipment  that  is  utilized 
during  the  radar  tests  and  also  at  other  times. 

Spikes.  A  significant  feature  seen  sporadically  in  the  recorded  data  is  a  large  spike  or  pulse 
which  is  isolated  from  other  effects,  but  is  sometimes  associated  with  the  acquisition  or  loss  of  a 
satellite  and  occasionally  associated  with  a  subsequent  data  dropout.  A  spike  appears  to  be  a 
single  wild  data  sample  (at  a  6-second  sampling  interval),  while  a  pulse  is  distinctly  composed  of 
many  data  samples. 

The  spikes  or  pulses  do  not  appear  on  multiple  satellites  at  their  time  of  occurrence,  and 
range  in  amplitude  from  about  50  TEC  units  (the  typical  limit  of  detectability)  to  about  450  TEC 
units.  The  presence  of  the  RF  band-pass  filter  does  not  appear  to  influence  the  occurrence  of 
spikes,  but  further  data  collection  without  the  RF  filter  would  be  needed  to  make  a  statistically 
significant  comparison.  The  large  spikes  do  not  appear  to  be  associated  with  the  operation  of  the 
radar,  but  smaller  ones  sometimes  do  appear  during  radar  events,  possibly  as  the  largest  of 
several  pulses  in  a  pulse  train  becoming  visible  above  the  typical  noise  and  multipath  level. 

Multipath.  The  multipath  pattern  appeared  to  be  consistent  over  the  first  two  days  of  data 
collection,  even  without  the  RF  filter,  so  further  days  were  not  examined  in  detail  for  the 
consistency  of  this  pattern.  The  incorporation  of  the  RF  filter  had  been  examined  previously  at 
Hanscom,  and  was  determined  to  have  no  deleterious  effects  on  the  GPS  signals. 

The  DGD  noise/multipath  amplitude  at  low  elevations  is  substantial,  often  on  the  order  of 
100-200  TEC  units.  The  current  provisions  utilizing  an  elevation  threshold  for  data  acquisition 
may  require  re-evaluation  of  this  parameter  after  the  IMS  is  installed,  with  some  associated 
change  in  the  region  covered  by  the  observations. 
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Ongoing  Investigations.  Inquiries  were  conducted  with  regard  to  the  operations  of  other 
equipment  at  the  site,  particularly  those  in  the  vicinity  of  the  GPS  antenna,  to  evaluate  the 
possibility  of  interference  sources  that  are  distinct  from,  but  often  coordinated  with,  the  radar 
operation.  These  discussions  indicated  that  neither  the  radar  nor  other  instrumentation  on  the 
roof  of  the  radar  building  was  the  source  of  the  interference,  but  that  another  activity  was  the 
source.  Further  details  are  expected  at  the  time  of  the  installation  visit,  when  the  antenna-siting 
evaluation  will  be  concluded. 

The  influence  of  the  extraneous  effects  on  the  phase-averaging  process  is  being  evaluated 
quantitatively,  using  techniques  that  have  already  been  developed  for  other  investigations.  A 
preliminary  determination  for  the  elevation  threshold  will  be  part  of  this  evaluation.  Tentative 
conclusions  are  that  only  the  very  largest  discrete  events  (spikes  and  pulses)  will  pose  a  long¬ 
term  problem  for  phase-averaging,  but  the  multipath  may  be  a  significant  concern. 
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Appendix  B:  wbmgrid  User’s  Manual 

The  User’s  Manual  written  for  the  wbmgrE)  programs  is  attached  as  an  appendix  to  this  report. 
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Overview 


Four  programs  make  up  the  wbmgrid  code:  llgrid,  GEOMGRID,  irrgrid,  and  s4grid.  Each  of 
these  programs  reads  user  inputs  from  an  ASCH-format  file  (or  a  collection  of  files),  grid  files  generated 
by  other  programs  "upstream"  in  the  processing  chain,  and  outputs  one  or  more  grid  files  containing 
processing  results.  The  primary  function  of  each  program  is  as  follows: 

llgrid:  Generate  a  grid  file  containing  the  definition  of  the  latitude-by-longitude  grid  to  be  used  by 
later  programs.  This  grid  file  is  tailored  to  a  single,  user-specified  geostationary  satellite 
location. 

GEOMGRID:  Generate  two  grid  files  containing  all  static  geometry  information  used  by  the  ionosphere 
model  in  iRRGRiD  and  the  propagation  model  in  s4grid. 

IRRGRID:  Generate  a  grid  file  of  the  parameters  used  to  characterize  ionospheric  plasma-density  irregu¬ 
larities  for  the  propagation  model.  This  is  based  on  climatology,  climatology  adjusted  by  an 
SSIES  analysis,  or  climatology  scaled  by  real-time  observations. 

s4grid:  Generate  a  file  of  S4  values  based  on  the  irregularity  parameters  read  from  the  file  built  by 
IRRGRID  and  modified  by  other  codes  (to  add  discrete  plume  structures). 

These  programs  were  designed  so  that  the  geometry  of  the  scenario  (as  calculated  by  programs  llgrid  and 
geomgrid)  need  only  be  calculated  when  either  the  definition  of  the  grid  changes  (spacing  or  lati¬ 
tude/longitude  range)  or  the  location  of  the  satellite  changes. 

Subsequent  sections  will  present  the  structure  and  contents  of  the  inputs  file,  the  output  files,  more 
detail  on  the  processing  and  calculations  made  within  each  program,  and  the  error  behavior  of  the 
system. 


Inputs  File 

User  inputs  to  all  four  programs  are  controlled  via  a  user  interface  library  (UINLIB)  which  provides 
a  NAMELIST-like  protocol  that  is  both  flexible  and  portable.  The  library  will  allow  input  from  either  an 
external  ASCH-format  file  or  from  the  standard  input,  with  the  determination  of  the  input  source  made 
via  command-line  inputs  to  the  program  (for  a  UNIX  implementation).  The  general  form  for  inputs  are 
the  keyword  name  of  the  input  starting  at  the  beginning  of  an  input  line  followed  by  an  equal  sign  (=) 
followed  by  one  or  more  input  values.  In  each  program,  some  of  the  inputs  are  required,  and  others  are 
optional.  If  an  optional  input  is  missing,  the  program  will  substitute  a  default  value  for  that  input. 
Comments  may  be  placed  in  an  inputs  file  by  placing  two  minus  signs  (-)  at  the  start  of  the  line.  Unlike 
the  NAMELIST  facility,  input  character  strings  (such  as  file  names)  are  not  enclosed  in  single  quotes  (')• 
Order  of  inputs  within  the  file  is  arbitrary,  with  the  exception  of  table  input  (see  the  discussion  under 
program  IRRGRID).  All  keywords  must  be  spelled  correctly,  and  with  the  correct  case  (upper  or  lower). 
Keywords  cannot  have  embedded  blanks,  so  several  of  them  use  the  underscore  character  (_)  for  a  blank. 
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The  library  is  designed  so  that  all  inputs  not  recognized  by  a  particular  program  are  simply  ignored. 
This  permits  the  generation  of  a  single  inputs  file  that  contains  all  inputs  for  a  particular  run  of  the  entire 
set  of  programs.  An  example  of  an  inputs  file  for  a  full  run  of  all  four  WBMGRID  programs  is  shown  in 
Appendix  A.  A  discussion  of  the  inputs  specific  to  an  individual  program  will  be  postponed  until  the 
description  of  that  program.  There  are,  however,  a  number  of  inputs  in  this  file  that  are  common  to  all 
programs;  these  will  be  discussed  here. 

The  following  is  an  example  of  the  inputs  file  that  would  be  common  to  all  programs: 


General  Inputs  -  All  Programs 


Inputs_File__Built  =  03  June  1996  /  12:30:22  GMT 

-  Run  Control  Information  - 

Run_llgrid  =  1 
Run_geomgrid  =  1 
Run_irrgrid  =  1 
Run_s4grid  =  1 

-  Diagnostic  Print  Control  - 

IO_DiagPrtFlag  =  1 
Proc_DiagPrtFlag  =  0 

-  Files  Information  - 

Grid^File  =  grid_def.bin 
Geometry_File  =  geom_def.bin 
EqGeometry„File  =  eqgeom__def.bin 
Irregular ity_File  =  irrgrid.bin 
S4_File  =  s4grid.bin 


The  contents,  use,  and  (if  any)  defaults  for  each  of  these  are  as  follows: 

inputs_Fiie_Buiit :  This  is  a  character  string  that  can  have  any  format,  but  is  designed  to  have  the 
date  and  time  that  the  inputs  file  was  built,  either  by  hand  or  as  output  from  a  GUI-based  control 
program.  This  string  is  output  by  each  program  to  standard  output  as  soon  as  it  is  read.  If  this  is 
missing,  nothing  is  output. 

Run_iigrid  :  This  flag  is  used  to  control  whether  program  LLGRID  will  run  after  reading  this  inputs  file. 
If  set  to  zero  (0),  the  program  will  exit  without  further  processing.  If  set  to  one  (1),  the  program 
will  continue  and  process  normally.  This  permits  the  programs  to  be  placed  in  a  single  "canned" 
execution  script  that  never  changes  from  mn  to  run.  Whether  a  particular  program  runs  or  not  is 
controlled  by  flags  in  the  inputs  file.  This  will  be  discussed  further  in  a  later  section  that 
describes  an  implementation  of  these  programs.  [Default:  0  (no  run)] 

Run_geomgrid :  Same  as  above  for  the  GEOMGRID  program. 

Run_irrgrid  :  Same  as  above  for  the  IRRGRID  program. 

Run_s4grid  :  Same  as  above  for  the  s4grid  program. 

io_DiagPrtFiag  :  This  flag  controls  the  generation  of  diagnostic  output  concerning  input  and  output 
operations.  It  is  designed  for  use  in  debugging  the  programs  or  in  tracking  down  execution  errors 
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during  operations.  If  set  to  zero  (0),  I/O  diagnostic  output  is  suppressed;  if  set  to  one  (1),  it  is 
enabled.  This  input  should  either  be  set  to  0  or  left  out  entirely  for  operational  use.  [Default:  0 
(print  suppressed)] 

Proc_DiagPrtFlag  :  This  flag  controls  the  generation  of  diagnostic  output  concerning  all  processing.  It 
is  designed  for  use  in  debugging  the  programs  or  in  tracking  down  execution  errors  during  opera¬ 
tions.  If  set  to  zero  (0),  processing  diagnostic  output  is  suppressed;  if  set  to  one  (1),  it  is  enabled. 
This  input  should  either  be  set  to  0  or  left  out  entirely  for  operational  use.  [Default:  0  (print 
suppressed)] 

Grid_Fiie  :  Name  of  the  (binary)  output  file  built  by  program  llgrid.  [Default:  grid.bin] 
Geometry_Fiie  :  Name  of  the  (binary)  output  geometry  file  built  by  program  geomgre).  [Default: 

geom.bin] 

EqGeometry_Fiie  :  Name  of  the  (binary)  output  equatorial  geometry  file  built  by  program  GEOMGRID. 
[Default:  eqgeom .  bin] 

Irregular ity^piie  :  Name  of  the  (binary)  output  irregularity-parameters  file  built  by  program 
IRRGRID.  [Default:  irrgrid.bin] 

S4_File:  Name  of  the  (binary)  output  S4  file  built  by  program  s4grid.  [Default:  s4grid.bin] 


Binary  Grid  File  Descriptions 

The  WBMGRID  system  uses  one  or  more  ASCH-format  inputs  files  (one  for  each  program  or  one  for  a 
run  of  the  entire  system),  five  binary-format  grid  files,  an  optional  ASCH-format  grid-definition  input 
file,  and  an  optional  ASCH-format  CkL  latitude-function  output  file.  The  inputs  file  was  described  in  the 
last  section,  and  the  two  optional  ASCH-format  files  will  be  discussed  under  programs  llgrid  and 
IRRGRID,  respectively.  The  format  and  contents  of  the  five  binaiy-format  grid  files  will  be  presented 
here. 

All  of  the  binary  grid  files  have  the  same  general  format:  a  one-record  (I/O  record)  header  followed 
by  grid-data  FO  records.  The  headers  contain  file-verification  information  (ID  flags  and  date/time 
generated  information)  and  other  information  concerning  the  size  and  contents  of  the  rest  of  the  file. 
The  grid-data  FO  records  contain  entries  for  100  grid  points.  The  size  of  the  FO  records  are  different  for 
each  file,  as  the  size  of  the  grid-point  entries  for  each  is  different.  Tables  1  through  5  in  Appendix  B 
describe  the  contents  of  the  headers  and  FO  records  for  each  of  the  five  binary  files  defined  to  date 

(grid.bin,  geom.bin,  eqgeom.bin,  irrgrid.bin,  and  s4grid.bin) 
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Program  Descriptions 

Program  LLGRID 

Program  llgrid  constructs  a  file  (grid.bin,  see  Table  1)  that  contains  the  latitude  and  longitude  of 
each  grid-point  for  which  later  programs  will  calculate  their  various  parameters.  This  grid  is  defined  as 
an  equally  spaced  latitude-by-longitude  grid  centered  (initially)  on  the  latitude  and  longitude  of  the 
geostationary  satellite  to  which  the  propagation  paths  lead.  The  bounds  of  the  grid  are  defined  initially 
by  a  minimum  elevation  angle,  and  can  be  further  limited  by  input  of  minimum  and  maximum  latitude 
and  longitude  values.  In  addition  to  the  general  inputs  described  earlier,  the  program-specific  inputs  to 
LLGRID  are  as  follows: 

Required  Inputs: 

Sateilite_Latitude  :  Latitude  of  the  geostationary  satellite  (degrees,  +north). 
satellite_Longitude  :  Longitude  of  the  geostationary  satellite  (degrees,  +east). 

Satellite_Aititude  :  Altitude  of  the  geostationary  satellite  (km). 

sateilite_veidcity  :  Satellite  velocity  vector  (m/s).  Three  entries  are  required  to  define  the  velocity 
vector:  (+north,  +east,  +down). 

Optional  Inputs: 

Latitude_Spacing  :  Grid  spacing  in  latitude  (degrees)  [Default:  1.0]. 

Longitude_spacing  :  Grid  spacing  in  longitude  (degrees)  [Default:  1.0]. 

Minimum_Eievation  :  Minimum  elevation  angle  to  define  the  edge  of  the  coverage  area  (degrees) 
[Default:  10.0]. 

Latitude_Limits  :  Grid  limits  in  latitude  (degrees,  +north).  Two  entries  are  required:  southern  edge 
and  northern  edge.  Enter  -999.0  to  default  either  side  to  the  limits  set  by  Minim\iin_Elevation. 
[Default:  -999.0  -999.0]. 

Longitude_Limits  :  Grid  limits  in  longitude  (degrees,  +east).  Two  entries  are  required:  western  edge 
and  eastern  edge.  Enter  -999.0  to  default  either  side  to  the  limits  set  by  Minimum_Elevation. 
[Default:  -999.0  -999.0]. 

Grid_Def_Fiie  :  Name  of  an  ASCII-format  input  file  containing  information  for  each  grid  point  to  be 
used  in  calculations  by  the  other  WBMGRID  programs.  This  information  will  be  transferred  to  the 
binary-format  grid-definition  file.  All  other  optional  inputs  will  be  ignored. 

This  last  optional  input  permits  a  user  to  explicitly  specify  the  latitude/longitude  grid  to  be  used 
rather  than  having  LLGRID  construct  it  from  the  other  inputs.  The  format  of  this  ASCII  file  is  as  follows 
(all  lines  are  read  using  free-format  input): 
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Line  1:  glato  dlat  glonO  glon  npts 

giato  :  Base  latitude  (most  southerly  latitude  in  grid  (deg) 
dlat :  Latitude  spacing  (deg) 

glonO  :  Base  longitude  (most  easterly  longitude  in  grid  (deg) 

dlon ;  Longitude  spacing  (deg) 

npts  :  Total  number  of  grid  points  in  the  file 

Lines  2  through  npts+i:  nlat  nlon  glat  glon  ghgt  az  el 

niat :  Grid-point  latitude  number 
nlon  :  Grid-point  longitude  number 
glat :  Grid-point  latitude  (deg,  north) 
glon  :  Grid-point  longitude  (deg,  east) 
ghgt :  Grid-point  altitude  (km) 

az  :  Azimuth  angle  to  satellite  (deg,  clockwise  from  north) 
el :  Elevation  angle  to  satellite  (deg) 

Linenpts+2:  -i 

The  grid-point  numbers  are  simply  the  number  of  latitude  or  longitude  spacing  steps  the  grid  point  is 
removed  from  the  base  latitude  or  longitude  plus  1.  Note  that  it  is  important  that  the  directional  informa¬ 
tion  (elevation  and  azimuth  angles)  to  the  satellite  from  each  grid  point  needs  to  be  consistent  with  the 
satellite  location  input  via  the  inputs  file. 

Program  GEOMGRID 

Program  GEOMGRID  constructs  two  files  (geom.bin  and  eqgeom.bin.  Tables  2  and  3  in  Appendix 
B),  which  contain  all  necessary  time-independent  geometry  parameters  required  by  the  irregularity- 
model  and  propagation  calculations  at  each  grid  point  specified  in  the  file  built  by  program  LLGRID.  Two 
files  are  generated  in  order  to  conserve  space:  not  all  grid  points  will  require  a  number  of  the  parameters 
that  are  used  to  drive  the  WBMOD  CkL  model  in  the  equatorial  and  anomaly  crest  regions.  These  parame¬ 
ters  (as  defined  in  Table  3  of  Appendix  B)  are  calculated  only  for  those  grid  points  within  35°  of  the  dip 
equator.  This  program  requires  no  information  from  the  ASCII  inputs  file  beyond  the  general  inputs 
described  earlier. 

Program  IRRGRID 

Program  IRRGRID  constructs  a  file  (irrgrid.bin.  Table  4  in  Appendix  B)  that  contains  the  parame¬ 
ters  that  define  ionospheric  plasma-density  irregularities  at  each  point  on  the  grid  defined  in  the  grid- 
definition  file  built  by  llgrid.  This  code  includes  the  models  for  these  parameters  from  the  wbmod 
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program  (Version  13.04)  and  algorithms  to  adjust  or  replace  the  climatology  with  information  from  real¬ 
time  observations  (described  in  a  later  section).  Inputs  to  the  program  include  the  following: 

Required  Inputs: 

Date  :  Date  for  the  run  (GMT;  year,  month,  and  day). 

Time  :  Time  for  the  run  (GMT;  hours  and  minutes). 

Fio  :  The  10.7cm  solar  radio  flux  (janskys). 

Kp  :  3-hour  Kp  geomagnetic  index. 

Percentile  :  Percentile  in  log(CkL)  PDF  (percent).  This  is  only  used  when  the  model  is  run  strictly  in 
climatology  mode,  i.e.,  when  there  are  no  real-time  data  other  than  SSN  and  Kp. 

Optional  Inputs: 

Kp(ss)  :  Kp  at  sunset.  [Default:  user-input  Kp] 

Kp{ssj4)  :  Effective-Kp  derived  from  SSJ/4  boundary  observations.  [Default:  user-input  Kp] 

Drift_velocity-:  The  in-situ  drift  velocity  of  the  irregularities  (m/s).  Three  inputs  are  required  to 
define  the  velocity  vector:  (-Pnorth,  +east,  +down).  [Default:  internal  model]  [Note:  This  input 
is  currently  for  testing  purposes  only.] 

Real-time  Data  Inputs: 

ssiES_DateTime  :  The  GMT  date  (YYMMDD)  and  time  (HHMM)  of  an  SSIES  analysis,  two  entries 
separated  by  one  or  more  blank  spaces.  This  is  defined  as  the  time  of  the  equator  crossing  for  the 
pass  from  which  the  analysis  was  made.  If  this  entry  is  missing  from  an  inputs  file,  the  program 
assumes  there  is  no  SSIES  analysis  available  and  will  ignore  the  next  three  inputs  if  they  are  in 
the  file. 

ssiES_Longitude  :  Geographic  longitude  of  the  equator  crossing  from  the  pass  used  in  the  analysis 
(degrees  east). 

ssiES_Anaiysis  :  Results  of  the  SSIES  analysis.  A  number  ranging  from  0.0  (no  plume  development 
expected)  to  1.0  (plume  development  expected).  Details  of  how  this  is  used  will  be  presented 
later. 

ssiES_Kp  :  The  3-hour  Kp  index  valid  at  the  time  of  the  SSIES  analysis  {i.e.,  at  the  equator-crossing 
time). 

RT_Longitude_Limits  :  Geographic  longitude  limits  of  the  region  which  is  to  be  updated  with  real¬ 
time  observations  of  equatorial  plume  structures  (degrees  east).  Two  values  are  input:  the 
westernmost  longitude  followed  by  the  easternmost  longitude.  These  structures  are  added  by  the 
GUI  control  program.  If  there  are  not  data  available  from  which  the  structures  can  be  generated, 
either  do  not  include  these  in  the  inputs  file  or  set  both  of  these  inputs  to  0.0  to  indicate  that  the 
program  should  generate  the  entire  grid  based  on  the  WBMOD  climatology  (based  on  an  SSIES 
analysis  if  one  is  available).  [Note:  These  limits  are  converted  to  geomagnetic-longitude  region 
boundaries  by  the  program.  Geomagnetic  latitude  boundaries  are  set  internally  to  ±20°.]  All  grid 
points  that  are  within  the  real-time  analysis  region  will  have  CkL  values  set  to  the  non-plume  CkL 
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value  (input  described  below)  and  will  have  the  real-time  flag  in  the  irrgrid.bin  and 
s4grid.bin  files  set  tO  1. 

j^a3.ysis _ Longitud©  t  Geographic  longitude  centered  on  the  location  of  the  real-time  scintillation 

observations  that  are  to  be  used  in  the  analysis  (degrees  east).  If  this  is  not  input,  it  will  be  set  to 
either  (1)  the  longitude  determine  to  be  the  center  of  the  input  observations,  (2)  the  center  of  the 
real-time  analysis  region  from  the  RT_Longitude_Liraits  inputs,  or  (3)  set  to  the  default,  in  that 
order.  [Default:  280.0  degrees] 

NonPiume_ckL  :  The  CkL  observed  outside  plume  structures.  This  value  is  used  to  "fill"  the  real-time 
analysis  region.  [Default:  WBMOD  values  for  the  non-plume  population] 

Q3^L_obs©3rv3.tions _ ^Tabl©  :  This  keyword  indicates  the  start  of  a  table  of  CkL  values  derived  from  real¬ 

time  scintillation  measurements.  The  format  of  this  table  is  as  follows: 

CkL_Observations_Table 
YYMMDD  HHMM  GLAT  GLON  CKL 

YYMMDD  HHMM  GLAT  GLON  CKL 

YYMMDD  HHMM  GLAT  GLON  CKL 

YYMMDD  HHMM  GLAT  GLON  CKL 

END_OF_TABLE 

The  latitude  and  longitude  are  the  geographic  (degrees  +north  and  +east)  coordinates  of  the  350 
km  ionospheric  penetration  point  (IPP)  of  the  propagation  path  on  which  the  CkL  value  was 
measured.  This  table  can  have  up  to  100  separate  entries,  and  must  be  terminated  by  the 
END_OF_TABLE  String.  Details  of  what  should  be  in  this  table  and  how  the  data  are  used  will  be 
presented  later. 

ckL_Latitude_Fiie  :  Name  of  the  CkL  latitude-variation  output  file.  [Default:  No  output  file] 

If  the  last  optional  parameter  is  input,  it  will  cause  the  program  to  build  an  ASCH-format  output  file 
that  provides  the  variation  of  log(CkL)  with  geomagnetic  (apex)  latitude  in  one  degree  steps  from  -20°  to 
+20°  at  the  time  of  peak  scintillation  levels  as  defined  by  the  wbmod  model  (approximately  1.5  hours 
after  local  sunset).  The  variation  is  based  on  the  analysis  of  the  real-time  SSIES  and  scintillation  data 
used  in  producing  the  output  grid  file.  This  file  has  a  two-line  header  labeling  the  columns  followed  by 
two  columns  with  the  geomagnetic  (apex)  latitude  and  the  log(CkL)  value  at  that  latitude.  If  this  file¬ 
name  parameter  is  not  present  in  the  inputs  file,  this  file  will  not  be  constructed.  An  example  of  this  file 
is  given  in  Appendix  B. 

The  real-time  analysis  flag  output  to  the  grid  file  (and  included  in  the  s4grid  output  file)  is  an 
indicator  of  whether  a  grid  point  falls  within  the  region  where  analysis  of  real-time  scintillation 
observations  are  to  be  used  to  place  plume  structures.  This  flag  will  be  useful  for  generating  a  display  of 
the  fields  in  the  grid  files  that  differentiates  between  regions  where  the  analysis  is  based  on  climatology 
and  those  that  are  based  on  observed  structures.  This  region  is  bound  on  the  east  and  west  by  the 
geomagnetic  longitudes  passing  through  the  longitudes  specified  by  the  RT_Longitude_Limits  input  by 
the  user  and  on  the  north  and  south  by  ±20°  geomagnetic  latitudes.  Note  that  this  flag  has  nothing  to  do 
with  whether  real-time  CkL  measurements  were  used  to  scale  the  WBMOD-based  values  outside  the 
region  where  plume  structures  are  to  be  placed.  It  is  solely  to  be  used  in  later  display  of  the  grids. 

Program  s4grid 
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Program  s4grid  constructs  a  file  (s4grid.bin.  Table  5  in  Appendix  B)  that  contains  the  S4  values 
calculated  from  the  irregularity  parameters  in  the  file  built  by  IRRGRID.  The  program  uses  the  propaga¬ 
tion  code  from  the  wbmod  program  (Version  13).  Inputs  to  the  program  are  as  follows  : 

Required  Inputs: 

Frequency:  System  frequency  (MHz). 


Use  of  Real-Time  Inputs 

Input  of  real-time  observations  to  the  WBMGRID  programs  is  either  via  the  inputs  file  to  program 
IRRGRID  or  through  input  of  a  modified  grid  of  CkL  values  to  program  s4grid  (i.e.,  by  introducing 
discrete  plume  structures  in  the  irrgrid.bin  file  after  it  has  been  generated  by  the  IRRGRID  program  and 
before  s4grid  has  been  run).  This  section  will  discuss  the  real-time  input  options  to  the  IRRGRID 
program. 

There  are  two  sources  of  real-time  inputs  to  IRRGRID:  estimates  of  the  likelihood  of  plume  produc¬ 
tion  in  the  post^unset  equatorial  region  based  on  analysis  of  data  from  the  DMSP  SSIES  sensor 
package,  and  estimates  of  the  CkL  parameter  calculated  from  ground-based  scintillation  measurements. 
Generation  of  the  SSIES  analysis  and  of  the  CkL  estimates  are  to  be  done  by  either  the  controlling  GUI 
program,  or  by  another  program  controlled  by  the  GUI.  Program  IRRGRID  expects  these  analysis  and 
calculation  to  be  completed,  and  the  results  input  via  the  inputs  file  using  the  keywords  as  specified  in  an 
earlier  section. 

The  use  of  real-time  data  within  IRRGRID  is  as  follows: 

1.  If  no  real-time  data  are  input  (SSIES  or  CkL),  the  parameters  output  on  the  grid  are  based  solely  on 
the  WBMOD  climatology  using  the  input  F10.7  and  Kp  values.  The  real-time  analysis  flag  output  to  the 
grid  file  (variable  irt)  will  be  set  to  zero  at  all  grid  points. 

2.  If  only  an  SSIES  analysis  is  input  and  is  determined  to  be  valid,  it  will  be  used  to  set  the  position  in 
the  climatological  distribution  of  CkL  to  either  the  plume  (analysis  value  >  0.5)  or  the  nonplume 
(analysis  value  <  0.5)  populations.  The  WBMOD  climatology  will  be  used  to  set  and  vary  all  other 
parameters.  The  real-time  analysis  flag  will  be  set  to  zero  at  all  grid  points  unless  a  real-time  analysis 
longitude  range  is  input.  In  that  case,  this  flag  will  be  set  to  one  within  that  range  (see  earlier  discussion 
of  this  flag). 

3.  If  CkL  values  are  input  via  the  observations  table,  they  will  be  used  to  adjust  the  latitude  variation  of 
CkL  in  the  regions  outside  the  real-time  analysis  region.  Inside  that  region,  the  CkL  will  be  set  to  the 
nonplume  CkL  value  (either  explicitly  input  or  derived  from  the  nonplume  WBMOD  population).  The 
real-time  analysis  flag  will  be  set  to  zero  outside  the  region  and  set  to  one  inside  it. 

The  IRRGRID  program  determines  whether  an  input  SSIES  analysis  is  valid  for  the  grid  being 
constructed  according  to  the  following  scheme: 
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1 .  :  If  any  of  the  inputs  are  missing  (date,  time,  longitude,  Kp,  analysis),  don  t  use  it. 

2.  :  If  the  analysis  is  more  than  three  hours  old,  don't  use  it. 

3.  :  If  the  Kp  input  for  the  grid  is  more  than  2  Kp-units  different  than  Kp  at  the  time  of  the  SSEES 
analysis,  don't  use  it. 

4.  :  If  the  longitude  difference  between  the  analysis  and  the  sunset  terminator  at  the  time  of  the  grid  is 
larger  than  a  longitude-dependent  distance,  don't  use  it. 

This  last  criterion  is  based  on  the  longitude  variation  of  the  geomagnetic  declination  (basically  the  angle 
between  the  geographic  and  geomagnetic  meridians  at  the  equator)  and  the  model  for  the  effect  of  this 
variation  on  the  probability  of  plume  generation  used  in  WBMOD.  The  full  rationale  for  this  is  discussed 
in  Appendix  C,  but  the  basic  idea  is  that  within  longitude  sectors  where  the  declination  is  not  changing 
appreciably  with  longitude  the  permitted  longitude  distance  between  the  SSIES  analysis  and  its  applica¬ 
tion  is  larger  than  the  size  of  the  region.  In  sectors  where  the  declination  is  changing  rapidly  with  longi¬ 
tude,  the  longitude  difference  is  limited  to  15°  of  longitude.  If  the  SSIES  analysis  and  the  sunset  longi¬ 
tude  are  in  different  sectors,  the  difference  is  limited  to  5°.  A  map  showing  the  boundaries  of  the  sectors 
can  be  found  in  Appendix  C. 

The  use  of  the  CkL  observations  is  more  complex  than  the  use  of  the  SSIES  analyses,  and  is  less 
general  in  that  it  is  expecting  the  inputs  to  come  from  a  particular  set  of  locations  (in  geomagnetic 
latitude),  hi  its  current  implementation,  it  expects  to  have  observations  from  an  equatorial  station  near 
the  dip  equator  (Ancon,  Peru),  an  equatorial  station  near  to  and  equatorward  of  the  anomaly  crest  region 
(Antofagasta,  Chile),  and  a  mid-latitude  station  near  to  and  poleward  of  the  anomaly  crest  region 
(Howard  AFB,  Panama).  The  program  looks  for  observations  at  geomagnetic  latitudes  near  to  +2° 
(Ancon),  -9°  (Antofagasta),  and  +20°  (Howard  AFB).  (In  this  context,  "near"  is  within  ±3°  latitude.) 
These  data  are  used  to  scale  the  latitude  variation  of  CkL  in  the  sections  of  the  grid  that  are  outside  the 
real-time  analysis  region  (i.e.,  at  those  grid  points  where  the  real-time  analysis  flag  is  zero). 

The  program  is  expecting  that  the  CkL  observations  in  the  inputs  file  (in  the 
ckL_observations_Tabie)  are  the  characteristic  CkL  values  for  the  time  indicated  on  the  input.  They 
are  used  to  set  the  maximum  CkL  in  the  post-sunset  region  at  the  equator  and  at  the  anomaly  crest.  The 
program  divides  the  inputs  into  day  and  night  observations  (based  on  the  time-past-sunset  time  used  in 
WBMOD)  and  into  equatorial  and  near-crest  observations.  In  each  latitude  regime,  the  maximum  night¬ 
time  CkL  is  selected  from  the  inputs  and  is  used  as  the  maximum  post-sunset  value.  The  same  is  done 
with  the  daytime  values. 
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The  following  algorithms  are  used  depending  on  what  data  are  available. 

1.  ;  If  daytime  equatorial  values  are  available,  set  the  daytime  CkL  to  the  average  of  the  two  equatorial 
stations. 

2.  :  If  nighttime  values  are  available  from  both  equatorial  stations,  adjust  the  CkL  levels  at  the  equator 
and  at  the  anomaly  crest  and  the  half-width  of  the  transition  function  between  the  peak  of  the  crest  and 
the  equator.  If  this  analysis  fails,  the  average  difference  in  log(CkL)  between  the  observations  and  the 
model  values  are  used  to  scale  the  latitude  variation  as  an  additive  adjustment  to  both  the  equatorial  and 
crest  maximum  values. 

3.  :  If  a  nighttime  value  is  available  from  only  one  equatorial  station  (Ancon  or  Antofagasta),  the  differ¬ 
ence  in  log(CkL)  between  the  observation  and  the  model  value  is  used  as  an  additive  adjustment  to  both 
the  equatorial  and  crest  maximum  values. 

4.  :  If  a  nighttime  value  is  available  from  the  mid-latitude,  near-crest  station  (Howard  AFB),  it  is  used  to 
set  the  transition  half-width  from  the  peak  of  the  anomaly  crest  into  the  mid-latitude  ionosphere. 

In  all  cases,  the  time  variation  both  prior  to  and  after  the  post-sunset  peaks  is  controlled  by  the  diurnal 
model  from  WBMOD. 


Sample  Implementation  and  Use 

Appendix  A  shows  a  sample  inputs  file  and  Unix  script  to  run  these  programs.  In  this  implementa¬ 
tion,  all  of  the  inputs  are  in  a  single  inputs  file  and  all  four  programs  are  run  every  time.  Whether  a 
particular  program  actually  runs  through  its  entire  processing  cycle  is  controlled  by  the  run  flag  in  the 
inputs  file.  The  inputs  file  is  generated  either  by  a  user  with  a  text  editor,  or  by  a  GUI  that  interfaces 
with  the  user  for  input  and  then  builds  the  inputs  file  and  starts  the  script. 

Consider  the  following  operational  scenario:  every  hour  two  forecast  grids  are  generated  for  a  fixed 
scenario  (Le.,  a  fixed  geographic  grid  to  a  fixed  satellite  geometry)  for  one  and  two  hours  in  the  future. 
A  GUI  will  control  execution  of  the  WBMGRE)  programs,  and  will  also  place  discrete  plume  structures 
into  the  irrgrid.bin  file  (updating  the  CkL  parameters  in  the  file  built  by  program  IRRGRID)  and  gener¬ 
ate  the  final  product  that  is  sent  to  the  customer.  The  wbmgrid  codes  would  be  run  as  follows: 

1. :  The  GUI  would  be  used  by  the  operators  to  build  the  grid  and  geometry  files  once.  The  inputs  file 
would  have  the  run  flags  for  programs  LLGRID  and  GEOMGRID  set  to  one  (1)  and  the  flags  for  programs 
IRRGRID  and  s4grid  set  to  zero  (0).  These  files  would  not  need  to  be  rebuilt  unless  the  scenario  changes 
in  some  way.  This  can  be  done  at  any  time  prior  to  running  the  codes  to  produce  the  irregularity  and  S4 
files.  The  only  inputs  required  in  the  inputs  file  are  the  general  inputs  and  those  for  programs  LLGRID 
and  GEOMGRID. 


46 


2.  :  When  a  forecast  is  to  be  run,  the  GUI  would  build  inputs  files  for  the  two  forecast  times  (one  and 
two  hours  in  the  future)  and  run  program  IRRGRID  with  both  inputs  files  to  build  two  irrgrid.bin 
output  files,  one  for  each  forecast  time 

3.  :  When  program  iRRGRiD  has  built  the  files,  the  GUI  can  then  run  the  plume-generation  software  to 
modify  the  irrgrid.bin  files  to  include  these  structures. 

4.  :  When  the  plume-stmcture  update  is  completed,  the  GUI  can  then  run  program  s4grid  on  both 
irrgrid.bin  forecast  files  to  generate  the  forecast  s4grid.bin  files.  .  The  run  flags  for  all  programs 
except  s4grid  are  set  to  zero  (0),  and  inputs  for  all  programs  other  than  s4grid  can  be  left  out  if  desired 
(they  will  be  ignored  by  s4grid  in  any  case). 

5.  ;  When  program  s4grid  has  built  the  files,  the  GUI  can  then  display  them  and  generate  any  products 
from  them. 


Error  Handling  Procedures 

All  of  the  WBMGRID  programs  have  been  designed  to  fail-safe,  by  which  we  mean  they  will 
recognize  error  situations  and  exit  from  them  in  an  orderly,  graceful  fashion.  Typical  failure  modes  are 
file  errors  (missing  files,  errors  reading  from  or  writing  to  files),  parameter  errors  (missing  parameters, 
misspelled  keywords  in  the  inputs  file,  missing  parameters  that  are  not  optional),  and  calculation  errors 
(logic  or  computation  errors  in  the  code).  The  first  two  modes  are  typically  up  to  the  user  to  correct  in 
one  way  or  another,  the  last  mode  will  typically  require  intervention  by  a  software  analyst. 

The  general  error-handling  procedures  in  all  four  programs  is  to  build  an  ASCII-format  text  file 
(errorsum.txt)  describing  the  error  and  then  terminating  with  a  non-zero  exit  status.  Prior  to  exiting, 
the  content  of  the  error-output  file  is  printed  in  the  standard  output  as  well.  An  error  message  has  the 
following  format: 

Error  Nuinber:  N.NN  /  Program:  PROGNAME 
Mess  age :  STRING 

-  Lines  of  additional  explanatory  information  - 


where  n.nn  is  the  error  number,  progname  is  the  name  of  the  program  in  which  the  error  was  encoun¬ 
tered,  and  STRING  is  a  one-line  explanation  of  the  error.  Between  the  two  lines  of  minus  signs  are  a  vari¬ 
able  number  of  lines  of  additional  information.  The  first  two  lines  in  the  file  will  always  have  the  format 
shown  here,  which  will  allow  a  GUI  running  the  codes  to  determine  what  sort  of  error  was  encountered 
and  help  the  user  rectify  things. 


47 


At  the  present  time,  the  following  errors  can  be  generated  (by  error  number): 

1  .XX  :  Errors  involving  the  inputs  file. 

1 . 10  :  The  inputs  file  was  missing  (an  error  return  from  an  attempt  to  open  the  file). 

1.20:  An  error  was  encountered  attempting  to  read  the  file  (typically  a  format  error). 
1.40:  An  input  parameter  was  in  error  (out  of  range,  etc.). 

1.50:  A  required  parameter  was  missing  from  the  inputs  file. 

2  -xx :  Errors  involving  a  grid  file  (input  or  output). 

2.10:  The  grid  file  was  missing  (an  error  return  from  an  attempt  to  open  the  file). 

2.20:  An  error  was  encountered  attempting  to  read  from  the  file. 

2.30:  An  error  was  encountered  attempting  to  write  to  the  file. 

2 . 40  :  A  structure  error  was  encountered  (problems  with  the  file  format,  header,  etc.). 
2.50:  An  end-of-file  was  encountered  when  one  was  not  expected  (the  file  was  too  small). 

3  .XX :  Program  errors  (computational  or  logic) 

3.10:  An  error  condition  was  encountered  involving  internal  program  operation. 

Actions  to  be  taken  are,  at  this  time,  TBD. 
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Appendix  A.  Sample  Implementation 

The  two  figures  in  this  appendix  show  a  sample  implementation  of  the  WBMGRID  programs.  Figure  1  is 
a  sample  inputs  file  that  runs  all  four  programs,  and  Figure  2  is  a  sample  Unix  script. 
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General  Inputs  -  All  Programs 


Inputs__File_Built  =  03  June  1996  /  12:30:22  GMT 

-  Run  Control  Information  - 

Run_llgrid  =  0 
Run_geomgrid  =  0 
Run_irrgrid  =  1 
Run_s4grid  =  0 

-  Diagnostic  Print  Control  - 

IO_DiagPrtFlag  =  0 
Proc_DiagPrtFlag  =  0 

-  Files  Information  - 

Grid_File  =  grid_def.bin 
Geometry_File  =  geom_def.bin 
EqGeometry_File  =  eggeom_def.bin 
Irregularity_File  =  irrgrid.bin 
S4_File  =  s4grid.bin 


-  Inputs  for  program  llgrid  - 


-  Satellite  Information  - 

Satellite_Latitude  =  0.0 
Satellite_Longitude  =  275.0 
Satellite_Altitude  =  36000.0 
Satellite_Velocity  =  0.0  3000.0  0.0 

-  Grid  Definition  Parameters  - 

Latitude^Spacing  =  1.0 
Longitude_Spacing  =1.0 
Minimum_Elevation  =  20.0 
Latitude_Limits  =  -34.0  18.0 
Longitude_Limits  =  256.0  310.0 
— Grid_Def_File  =  grid_ascii.dat 


Inputs  for  program  geomgrid  - 


There  are  none! 


-  Inputs  for  program  irrgrid  - 


-  Environment  Information  - 

Date  =  960320 
Time  =  0200 
FIO  =  120.0 
Kp  =  3.0 

Percentile  =  90.0 
Kp(SS)  =  2.0 
Kp(SSJ4)  =4.0 

-  R/T  Data  (from  analyses)  - 

RT_Longitude_Limits  =  260.0  305.0 
Analysis_Longitude  =  280.0 
—  SSIES  Analysis  Results 
SSIES_DateTime  =  19960320  013453 
SSIES_Kp  =4.0 
SSIES_Longitude  =  305.0 
SSIES_Analysis  =0.75 
--  CkL  Observations 
NonPlume_CkL  =  1.32E29 
CkL_Observations_Table 
960302  1211  -14.35  225.15  1.52E33 
960302  1212  15.35  226.15  2.62E33 

960302  1213  -2.35  227.15  3.72E33 

END_OF_TABLE 

-  CkL  Latitude  Function  Output  File  - 

CkL_Latitude_File  =  lckl_v_lat.dat 


-  Inputs  for  program  s4grid 


Frequency  =  250.0 


Figure  1.  Sample  WBMGRID  system  inputs  file. 


50 


#  Script  for  running  WBMGRID  programs. 

#  [Set  up  to  run  as  a  csh  script] 

#  01  June  1996 

#  Copyright  1996,  Northwest  Research  Associates,  Inc. 

# 

#  Set  the  name  of  the  inputs  file  to  process. 

# 

if({$#argv}  ==  0)then 

set  INPUTFILE  =  testinputs.dat 


else 

set  INPUTFILE  =  $argv[l] 
endif 
# 

#  Make  sure  that  the  inputs  file  exists. 

# 

if ( ! (-e  $INPUTFILE) ) then 

echo  ’ERROR:  Inputs  file  does  not  exist’ 
echo  ‘  File  name  requested:  '$INPUTFILE 

exit 

endif 

#  ... 

#  Set  the  name  of  the  directory  (full  path)  in  which  the  various 

#  executables  reside. 

# 

set  BINDIR  =  /home/salsa/ j im/afpl0067/grids/bin 


# 

#  List  out  the  inputs  file. 

# 

echo  ' ==========================================-====== - =  ==-= 

echo  ’Listing  of  inputs  file  :  '$INPUTFILE 
cat  $ INPUTFILE 

echo  ’ ==================================================-==  “ 

# 

#  Loop  over  the  programs . 

# 

foreach  program  {  llgrid  geomgrid  irrgrid  s4grid  ) 

# 

echo  STATUS:  Run  program  $program 
$BINDIR/$program  -f  $ INPUTFILE 
set  progstat  =  $status 
if{$progstat  1=  0)then 

echo  ’WARNING:  Bad  return  status  from  program  ’ $program 
echo  ■  Status  returned:  ’$progstat 

break 
endi  f 

echo  - - ' 

# 

end 


Figure  2.  Sample  Unix  script  for  running  the  WBMGRID  programs. 
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Appendix  B.  Format  of  Binary  Grid  Files 

The  tables  in  this  appendix  show  the  format  and  contents  of  the  five  grid  files  used  by  the  WBMGRID 
programs:  Table  1  describes  the  output  grid-definition  file  from  program  LLGRID,  Table  2  the  output 
geometry  file  from  program  GEOMGRID,  Table  3  the  output  equatorial-geometry  file  from  program 
GEOMGRID,  Table  4  the  irregularity-parameters  output  file  from  program  irrgrid,  and  Table  5  the  S4 
output  file  from  program  s4grid. 
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Record  ^1:  Header 

Words 

Name 

Contents 

1-5 

fileid 

Validator  string  (LLGridDefinitionFile) 

6 

iymd 

YYMMDD  file  was  built 

7 

ihms 

HHMMSS  file  was  built 

8 

nbout 

Number  of  I/O  buffers  in  file  (sans  header) 

9 

nrout 

Total  number  of  grid-point  records  in  file 

10 

nlats 

Number  of  latitudes  in  grid 

11 

glatO 

Initial  grid  latitude  (rad) 

12 

dlat 

Latitude  spacing  (rad) 

13 

nlons 

Number  of  longitudes  in  grid 

14 

glonO 

Initial  grid  longitude  (rad) 

15 

dlon 

Longitude  spacing  (rad) 

16 

el-min 

Minimum  elevation  angle  (rad) 

17 

gca-inax 

Corresponding  maximum  GCA  (rad) 

18 

glatJim(l) 

User-input  south  latitude  boundary  (rad) 

19 

glatJim(2) 

User-input  north  latitude  boundary  (rad) 

20 

glonJim(l) 

User-input  east  longitude  boundary  (rad) 

21 

glonJim(2) 

User-input  west  longitude  boundary  (rad) 

22 

slat 

Satellite  latitude  (rad) 

23 

slon 

Satellite  longitude  (rad) 

24 

shgt 

Satellite  altitude  (m) 

25 

vssg(l) 

Satellite  velocity  [-fN]  (m/s) 

26 

vssg(2) 

Satellite  velocity  [-1-E]  (m/s) 

27 

vssg(3) 

Satellite  velocity  [-I-D]  (m/s) 

Record  #2:  Grid-point  I/O  Record  #1 

Words 

Name 

Contents 

1 

Ibuf 

Number  of  grid-point  records  in  this  buffer 

2-8 

Grid-point  record  #1 

glat 

Grid-point  latitude  (rad) 

glon 

Grid-point  longitude  (rad) 

ghgt 

Grid-point  altitude  (m) 

az 

Ground-to-satellite  azimuth  (rad) 

el 

Ground-to-satellite  elevation  (rad) 

xlat 

Latitude  grid  index 

xlon 

Longitude  grid  index 

9-15 

Grid-point  record  #2 

Grid-point  record  #100 

Record  #3:  Grid-point  I/O  Record  7^2 

.  .  . 

Record  #N:  Grid-point  I/O  Record  #N-1 

Table  1.  Contents  and  format  of  file  grid.bin. 
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Record  #1:  Header 

Words 

Name 

Contents 

1-5 

fileid 

Validator  string  (MainGeometryFile) 

6 

iymd 

YYMMDD  file  was  built 

7 

ihms 

HHMMSS  file  was  built 

8 

nbout 

Number  of  I/O  buffers  in  file  (sans  header) 

9 

nrout 

Total  number  of  grid-point  records  in  file 

Record  #2:  Grid-point  I/O  Record  #1 

Words 

Name 

Contents 

1 

Ibuf 

Number  of  grid-point  records  in  this  buffer 

2-21 

Grid-point  record  #1 

rlat 

Grid-point  latitude  (rad) 

rlon 

Grid-point  longitude  (rad) 

az 

Ground-to-satellite  azimuth  (rad) 

el 

Ground-to-satellite  elevation  (rad) 

glatp 

IPP  latitude  (rad) 

glonp 

IPP  longitude  (rad) 

hp 

IPP  altitude  (m) 

vspg(l) 

Satellite  velocity  at  IPP  [-t-N]  (m/s) 

vspg(2) 

Satellite  velocity  at  IPP  [-|-E]  (m/s) 

vspg(3) 

Satellite  velocity  at  IPP  [-t-D]  (m/s) 

apxlat 

IPP  apex  latitude  (rad) 

apxlon 

IPP  apex  longitude  (rad) 

zr 

Reduced  propagation  range  (m) 

dec 

Magnetic  declination  at  IPP  (rad) 

phi 

Magnetic  ray  heading  at  IPP  (rad) 

psi 

Magnetic  dip  at  IPP  (rad) 

babs 

ABS (magnetic  field  strength)  at  IPP  (gauss) 

theta 

Ray  elevation  angle  at  IPP  (rad) 

nbufe 

I/O  buffer  record  for  equatorial  info 

irece 

I/O  buffer  record  index  for  equatorial  info 

22-41 

Grid-point  record  #2 

1982-2001 

Grid-point  record  #100 

Record  #3:  Grid-point  I/O  Record  #2 

,  .  . 

Record  #N:  Grid-point  I/O  Record  #N-1 

Table  2.  Contents  and  format  of  file  geom .  bin. 
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Record  #1:  Header 

Words 

Contents 

1-5 

fileid 

Validator  string  (EquatorialGeometryFile) 

6 

iymd 

YYMMDD  file  was  built 

7 

ilims 

HHMMSS  file  was  built 

8 

iibout 

Number  of  I/O  buffers  in  file  (sans  header) 

9 

nrout 

Total  number  of  grid-point  records  in  file 

Record  #2:  Grid-point  I/O  Record  #1 

Words 

Name 

Contents  . 

i 

Ibuf 

Number  of  grid-point  records  in  this  buffer 

2-17 

Grid-point  record 

^lat-pp^base 

Latitude  of  plume  base  PP  (rad) 

glon-pp_base 

Longitude  of  plume  base  PP  (rad) 

erlat_base(l) 

Latitude  of  N  E-region  base  point  (rad) 

erlat^base(2) 

Latitude  of  S  E-region  beise  point  (rad) 

erlon-base(l) 

Longitude  of  N  E-region  base  point  (rad) 

erlon-base(2) 

Longitude  of  S  E-region  base  point  (rad) 

decapx_base 

Magnetic  declination  at  base  PP  (rad) 

cglat_base 

COS(latitude)  of  base  apex  (rad) 

glat-ppJop 

Latitude  of  plume  top  PP  (rad) 

glon.pp.top 

Longitude  of  plume  top  PP  (rad) 

erlat_top(l) 

Latitude  of  N  E-region  top  point  (rad) 

erlat_top(2) 

Latitude  of  S  E-region  top  point  (rad) 

erlon_top(l) 

Longitude  of  N  E-region  top  point  (rad) 

erlon_top(2) 

Longitude  of  S  E-region  top  point  (rad) 

decapxJop 

Magnetic  declination  at  top  PP  (rad) 

cglat.top 

COS(latitude)  of  top  apex  (rad) 

18-33 

Grid-point  record 

1586-1601 

Grid-point  record  ^^100 

Record  :^3:  Grid-point  I/O  Record  #2 

Record  #N:  Grid-point  I/O  Record  #N-1 

Table  3.  Contents  and  format  of  file  eqgeom.bin. 
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Record  Header 

Words 

Name 

Contents 

1-5 

fileid 

Validator  string  (IrregularityFile) 

6 

iymd 

YYMMDD  file  was  built 

7 

ihms 

HHMMSS  file  was  built 

8 

nbout 

Number  of  I/O  buffers  in  file  (sans  header) 

9 

nrout 

Total  number  of  grid-point  records  in  file 

Record  #2:  Grid-point  I/O  Record  #1 

Words 

Name 

Contents 

1 

Ibuf 

Number  of  grid-point  records  in  this  buffer 

2-11 

Grid-point  record  #1 

a 

Along-field  axial  ratio 

b 

Cross-field  (L-shell)  axial  ratio 

delta 

Sheet/L-shell  normal  angle  (rad) 

alpha 

Outer  scale-size  (rad/m) 

q 

In-situ  spectral  slope 

ckl 

Height-integrated  spectral  strength  {CkL) 

rtsw 

Real-time  section  flag  (1:  R/T  section) 

vdpg(l) 

In-situ  drift  velocity  at  IPP  [-t-N]  (m/s) 

vdpg(2) 

In-situ  drift  velocity  at  IPP  [d-E]  (m/s) 

vdpg(3) 

In-situ  drift  velocity  at  IPP  [d-D]  (m/s) 

12-21 

Grid-point  record  #2 

992-1001 

Grid-point  record  i^lOO 

Record  #3:  Grid-point  I/O  Record  #2 

Record  #N:  Grid-point  I/O  Record  #N-1 

Table  4.  Contents  and  format  of  file  irrgrid.bin. 
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Record  #1:  Header 

Words 

Name 

Contents 

1-5 

fileid 

Validator  string  (S4File) 

6 

iymd 

YYMMDD  file  was  built 

7 

ihms 

HHMMSS  file  was  built 

8 

nbout 

Number  of  I/O  buffers  in  file  (sans  header) 

9 

nrout 

Total  number  of  grid-point  records  in  file 

Record  #2:  Grid-point  I/O  Record  #1  . 

Words 

Name 

Contents 

1 

Ibuf 

Number  of  grid-point  records  in  this  buffer 

2-3 

s4 

Grid-point  record 

s. 

rtsw 

Real-time  section  flag  (1:  R/T  section) 

4-5 

Grid-point  record  #2 

200-201 

Grid-point  record  #100 

Record  #3:  Grid-point  I/O  Record  #2 

Record  Grid-point  I/O  Record  #N-1 

Table  5.  Contents  and  format  of  file  s4grid.bin. 
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Appendix  C.  Longitude  Extrapolation  of  SSIES  Analyses 

Extrapolating  the  results  of  the  SSIES  analysis  in  longitude  is  complicated  by  the  fact  that 
conditions  affecting  the  possible  generation  of  plume  structures  vary  with  longitude.  Thus,  while  an 
SSIES  analysis  at  one  longitude  might  indicate  that  conditions  are  good  for  plume  generation,  this  might 
not  be  the  case  at  longitudes  not  too  far  removed  from  the  observation  longitude  due  to  significant  , 
changes  in  factors  that  affect  plume  growth.  In  particular,  the  longitude  variation  of  the  seasonal 
modulation  of  plume  generation  in  wbmod  is  based  on  a  hypothesis  put  forward  in  Tsunoda  [1985]  that 
plume  generation  will  be  most  likely  at  those  times  of  year  when  the  sunset  terminator  is  aligned  with 
the  local  geomagnetic  meridian.  In  addition,  recent  modeling  work  (such  as  in  Maruyama  [1988]  and 
Kelley  and  Maruyama  [1992])  suggest  that  the  component  meridional  neutral  winds  along  the 
geomagnetic  meridian  can  have  a  "braking"  effect  on  the  growth  of  plumes.  This  will  also  vary  in  some 
way  with  the  local  geomagnetic  declination  angle  near  the  equator.  Given  this,  we  have  decided  to 
permit  only  limited  extrapolation  of  SSIES  analyses  in  longitude  sectors  where  the  geomagnetic 
declination  angle  varies  significantly  with  longitude  and  between  sectors,  and  to  permit  unlimited 
extrapolation  in  sectors  where  the  declination  is  fairly  constant  in  longitude. 

Figure  3  illustrates  this  point  and  shows  the  division  of  the  equatorial  region  into  six  longitude 
sectors.  Unlimited  extrapolation  is  permitted  in  sectors  1,  3,  and  5;  extrapolation  is  permitted  by  up  to 
15°  in  longitude  in  sectors  2,  4,  and  6;  and  extrapolation  of  up  to  5°  in  longitude  is  permitted  from  one 
sector  to  the  next. 


Longitude  Variation  of  Equatorial  Parameters 
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Figure  3.  Longitude  variation  of  the  apex  (dip)  equator  (dashed  line)  and  the  magnetic  declination  at  the 
equator  (solid  line).  The  heavy  vertical  lines  indicate  boundaries  between  the  six  longitude  sectors 
used  in  the  SSIES  analysis. 
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